You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Rob Weir <ro...@apache.org> on 2011/11/17 20:16:52 UTC
Draft IP Review Plan for OpenOffice
I've consolidated and summarized the various bits of guidance we've
received on this list and on legal-discuss, and distill in down into
relevant guidance for this project. We don't need to all be experts
in this, but I think everyone contributing code needs to understand
the basics of what we may and may not do. Since I know that not
everyone has followed all the threads, I think it is worth bringing
this information together in one place, for easy reference.
Since this is my interpretation of Apache policy, or even my
interpretation of someone else's interpretation, I'd ask you treat
this as a draft for now. But please do review, ask questions, and
point out any information that you believe is incorrect.
https://cwiki.apache.org/confluence/display/OOOUSERS/IP+Plan+for+Apache+OpenOffice
Regards,
-Rob
RE: Draft IP Review Plan for OpenOffice
Posted by "Dennis E. Hamilton" <de...@acm.org>.
+1
This enumeration is working to ground a lot of considerations. Thanks Rob.
-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org]
Sent: Thursday, November 17, 2011 12:18
To: ooo-dev@incubator.apache.org
Subject: Re: Draft IP Review Plan for OpenOffice
On Thu, Nov 17, 2011 at 2:43 PM, TJ Frazier <tj...@cfl.rr.com> wrote:
> On 11/17/2011 14:16, Rob Weir wrote:
>>
>> I've consolidated and summarized the various bits of guidance we've
>> received on this list and on legal-discuss, and distill in down into
>> relevant guidance for this project. We don't need to all be experts
>> in this, but I think everyone contributing code needs to understand
>> the basics of what we may and may not do. Since I know that not
>> everyone has followed all the threads, I think it is worth bringing
>> this information together in one place, for easy reference.
>>
>> Since this is my interpretation of Apache policy, or even my
>> interpretation of someone else's interpretation, I'd ask you treat
>> this as a draft for now. But please do review, ask questions, and
>> point out any information that you believe is incorrect.
>>
>>
>> https://cwiki.apache.org/confluence/display/OOOUSERS/IP+Plan+for+Apache+OpenOffice
>>
>> Regards,
>>
>> -Rob
>>
>>
> Good job, and much needed.
> Comments:
> (a) For item #4 under "Guidance for Source Releases", I suggest:
>
> s/This/Producing a copy-left-free binary/
>
Done.
> (b) Some further explanation of the situation regarding class-X-licensed
> build components would be helpful. In order to build, AFAIK, we need all
> sorts of things, like dmake, epm, gcc, &c. These have to be present or
> downloaded, true?
I just added a #8 for that. These are not part of releases, but are
pre-req's either satisfied by the platform (on Linux or BSD) or via a
pre-req install, like Cygwin on Windows.
dmake -- I still don't see what we can do there. It is still a hard
dependency even if we host it elsewhere. We can't contribute it
upstream because the OOo project outlived the dmake upstream. We're
the only user of it now. But the copyleft license ensures. We should
discuss more after our initial release. Maybe we want to just slay
the dragon and get it over with, rewrite in GNU make.
-Rob
> --
> /tj/
>
>
Re: Draft IP Review Plan for OpenOffice
Posted by Rob Weir <ro...@apache.org>.
On Thu, Nov 17, 2011 at 2:43 PM, TJ Frazier <tj...@cfl.rr.com> wrote:
> On 11/17/2011 14:16, Rob Weir wrote:
>>
>> I've consolidated and summarized the various bits of guidance we've
>> received on this list and on legal-discuss, and distill in down into
>> relevant guidance for this project. We don't need to all be experts
>> in this, but I think everyone contributing code needs to understand
>> the basics of what we may and may not do. Since I know that not
>> everyone has followed all the threads, I think it is worth bringing
>> this information together in one place, for easy reference.
>>
>> Since this is my interpretation of Apache policy, or even my
>> interpretation of someone else's interpretation, I'd ask you treat
>> this as a draft for now. But please do review, ask questions, and
>> point out any information that you believe is incorrect.
>>
>>
>> https://cwiki.apache.org/confluence/display/OOOUSERS/IP+Plan+for+Apache+OpenOffice
>>
>> Regards,
>>
>> -Rob
>>
>>
> Good job, and much needed.
> Comments:
> (a) For item #4 under "Guidance for Source Releases", I suggest:
>
> s/This/Producing a copy-left-free binary/
>
Done.
> (b) Some further explanation of the situation regarding class-X-licensed
> build components would be helpful. In order to build, AFAIK, we need all
> sorts of things, like dmake, epm, gcc, &c. These have to be present or
> downloaded, true?
I just added a #8 for that. These are not part of releases, but are
pre-req's either satisfied by the platform (on Linux or BSD) or via a
pre-req install, like Cygwin on Windows.
dmake -- I still don't see what we can do there. It is still a hard
dependency even if we host it elsewhere. We can't contribute it
upstream because the OOo project outlived the dmake upstream. We're
the only user of it now. But the copyleft license ensures. We should
discuss more after our initial release. Maybe we want to just slay
the dragon and get it over with, rewrite in GNU make.
-Rob
> --
> /tj/
>
>
Re: Draft IP Review Plan for OpenOffice
Posted by Andre Fischer <af...@a-w-f.de>.
Hi Eric,
On 18.11.2011 10:00, eric b wrote:
> Hi Andre,
>
> Le 18 nov. 11 à 09:42, Andre Fischer a écrit :
>
>> On 17.11.2011 21:30, Dennis E. Hamilton wrote:
>>>
>>> There are some odd cases of abandonware having no authoritative
>>> location for downloading and also having OpenOffice.org-applied
>>> patches. I think dmake is one of those. I have no idea how that ends
>>> up but I think it means dmake disappears as a build prerequisite.
>>
>> I am currently working on removing the dmake sources.
>
>
> How do things work on Mac OS X ?and Windows ? Shall we install a "system
> one" using respectively Fink/Darwin port , Cygwin ?
A dmake installed on the system is probably preferable. It can be
shared between different child work spaces (I am using this term in the
widest sense), and reduces the build time (by a little bit.)
There is dmake package for Ubuntu but there is no dmake for cygwin.
Other environments may or may not have it. So, making it a system
prerequisite on systems that do not have it ready-made is probably not a
good idea.
>
>
>> There is another thread about this, but you can also have look at
>> issue 118604 for the techincal details. The basic idea is to use a
>> pre-installed dmake executable by default.
>
>
> FYI, OOo4Kids and OOoLight uses dmake too. Maybe this could help to
> build on Mac OS X and on Windows probably ? (see below)
>
>
>> However, the user can provide a URL for a downloadable tar-ball, which
>> then is downloaded and built in bootstrap.
>>
>
>
> Maybe a crazy idea, but what about download dmake sources from Adullact
> repo ?
>
> Try (in main) : svn co svn://svn.adullact.net/svnroot/ooo4kids1/trunk/dmake
>
> The good is this dmake version is directly usable everywhere. The bad is
> that you mix two svn sources (maybe not realistic ... ?)
Well, I could extend the --with-dmake-url configure option so that it
can not only download a tar-ball but can also check out from an SVN
repository. But the advantage of that is probably small. After all,
dmake is basically a dead project with little or no changes that would
require a frequent remaking of the tar-ball.
>
>
> Last but not least, Adullact is one big French non profit association,
> working close to french administration, reliable and with high ethical
> objectives. What about ask Adullact to host some problematic sources ?
Sure. Providing Apache OpenOffice specific versions of category X
licensed code may be a way to handle the modules that we are currently
removing. But I am not sure about the legal implications about hosting
code on a server that neither belongs to Apache nor the original author.
May be worth another thread.
Regards,
Andre
>
>
>
> Regards,
> Eric
>
Re: Draft IP Review Plan for OpenOffice
Posted by eric b <er...@free.fr>.
Hi Andre,
Le 18 nov. 11 à 09:42, Andre Fischer a écrit :
> On 17.11.2011 21:30, Dennis E. Hamilton wrote:
>>
>> There are some odd cases of abandonware having no authoritative
>> location for downloading and also having OpenOffice.org-applied
>> patches. I think dmake is one of those. I have no idea how that
>> ends up but I think it means dmake disappears as a build
>> prerequisite.
>
> I am currently working on removing the dmake sources.
How do things work on Mac OS X ?and Windows ? Shall we install a
"system one" using respectively Fink/Darwin port , Cygwin ?
> There is another thread about this, but you can also have look at
> issue 118604 for the techincal details. The basic idea is to use a
> pre-installed dmake executable by default.
FYI, OOo4Kids and OOoLight uses dmake too. Maybe this could help to
build on Mac OS X and on Windows probably ? (see below)
> However, the user can provide a URL for a downloadable tar-ball,
> which then is downloaded and built in bootstrap.
>
Maybe a crazy idea, but what about download dmake sources from
Adullact repo ?
Try (in main) : svn co svn://svn.adullact.net/svnroot/ooo4kids1/
trunk/dmake
The good is this dmake version is directly usable everywhere. The bad
is that you mix two svn sources (maybe not realistic ... ?)
Last but not least, Adullact is one big French non profit
association, working close to french administration, reliable and
with high ethical objectives. What about ask Adullact to host some
problematic sources ?
Regards,
Eric
--
qɔᴉɹə
Projet OOo4Kids : http://wiki.ooo4kids.org/index.php/Main_Page
L'association EducOOo : http://www.educoo.org
Blog : http://eric.bachard.org/news
Re: Draft IP Review Plan for OpenOffice
Posted by Andre Fischer <af...@a-w-f.de>.
On 17.11.2011 21:30, Dennis E. Hamilton wrote:
> I had thought that category X artifacts needed to accomplish a build would be excluded from the release but identified as prerequisites for the build. They would never be distributed in the Apache OpenOffice release. (I am becoming rapidly accustomed to using that name.)
>
> Some become downloaded by build procedures in order to be used, but they are never in the release itself. (Whether an ASF-hosted buildbot does such a thing is interesting but tangential, I think.)
>
> There are some odd cases of abandonware having no authoritative location for downloading and also having OpenOffice.org-applied patches. I think dmake is one of those. I have no idea how that ends up but I think it means dmake disappears as a build prerequisite.
I am currently working on removing the dmake sources. There is another
thread about this, but you can also have look at issue 118604 for the
techincal details. The basic idea is to use a pre-installed dmake
executable by default. However, the user can provide a URL for a
downloadable tar-ball, which then is downloaded and built in bootstrap.
-Andre
>
> Another case would be redistributables (e.g., a particular JRE version or Microsoft Visual C++ redistributables) that may end up in a binary distribution. This is a different situation, even though there can also be build-time prerequisites (e.g., on a JDK or Visual C++) as well as dependencies in the built binary distribution.
>
> TJ, do you see any other flavors, or have any other specific cases in mind.
>
> -----Original Message-----
> From: TJ Frazier [mailto:tjfrazier@cfl.rr.com]
> Sent: Thursday, November 17, 2011 11:44
> To: ooo-dev@incubator.apache.org
> Subject: Re: Draft IP Review Plan for OpenOffice
>
> On 11/17/2011 14:16, Rob Weir wrote:
> [ ... ]
>>
>> https://cwiki.apache.org/confluence/display/OOOUSERS/IP+Plan+for+Apache+OpenOffice
>>
>> Regards,
>>
>> -Rob
>>
>>
> Good job, and much needed.
> Comments:
> (a) For item #4 under "Guidance for Source Releases", I suggest:
>
> s/This/Producing a copy-left-free binary/
>
> (b) Some further explanation of the situation regarding class-X-licensed
> build components would be helpful. In order to build, AFAIK, we need all
> sorts of things, like dmake, epm, gcc,&c. These have to be present or
> downloaded, true?
RE: Draft IP Review Plan for OpenOffice
Posted by "Dennis E. Hamilton" <de...@acm.org>.
I had thought that category X artifacts needed to accomplish a build would be excluded from the release but identified as prerequisites for the build. They would never be distributed in the Apache OpenOffice release. (I am becoming rapidly accustomed to using that name.)
Some become downloaded by build procedures in order to be used, but they are never in the release itself. (Whether an ASF-hosted buildbot does such a thing is interesting but tangential, I think.)
There are some odd cases of abandonware having no authoritative location for downloading and also having OpenOffice.org-applied patches. I think dmake is one of those. I have no idea how that ends up but I think it means dmake disappears as a build prerequisite.
Another case would be redistributables (e.g., a particular JRE version or Microsoft Visual C++ redistributables) that may end up in a binary distribution. This is a different situation, even though there can also be build-time prerequisites (e.g., on a JDK or Visual C++) as well as dependencies in the built binary distribution.
TJ, do you see any other flavors, or have any other specific cases in mind.
-----Original Message-----
From: TJ Frazier [mailto:tjfrazier@cfl.rr.com]
Sent: Thursday, November 17, 2011 11:44
To: ooo-dev@incubator.apache.org
Subject: Re: Draft IP Review Plan for OpenOffice
On 11/17/2011 14:16, Rob Weir wrote:
[ ... ]
>
> https://cwiki.apache.org/confluence/display/OOOUSERS/IP+Plan+for+Apache+OpenOffice
>
> Regards,
>
> -Rob
>
>
Good job, and much needed.
Comments:
(a) For item #4 under "Guidance for Source Releases", I suggest:
s/This/Producing a copy-left-free binary/
(b) Some further explanation of the situation regarding class-X-licensed
build components would be helpful. In order to build, AFAIK, we need all
sorts of things, like dmake, epm, gcc, &c. These have to be present or
downloaded, true?
--
/tj/
Re: Draft IP Review Plan for OpenOffice
Posted by TJ Frazier <tj...@cfl.rr.com>.
On 11/17/2011 14:16, Rob Weir wrote:
> I've consolidated and summarized the various bits of guidance we've
> received on this list and on legal-discuss, and distill in down into
> relevant guidance for this project. We don't need to all be experts
> in this, but I think everyone contributing code needs to understand
> the basics of what we may and may not do. Since I know that not
> everyone has followed all the threads, I think it is worth bringing
> this information together in one place, for easy reference.
>
> Since this is my interpretation of Apache policy, or even my
> interpretation of someone else's interpretation, I'd ask you treat
> this as a draft for now. But please do review, ask questions, and
> point out any information that you believe is incorrect.
>
> https://cwiki.apache.org/confluence/display/OOOUSERS/IP+Plan+for+Apache+OpenOffice
>
> Regards,
>
> -Rob
>
>
Good job, and much needed.
Comments:
(a) For item #4 under "Guidance for Source Releases", I suggest:
s/This/Producing a copy-left-free binary/
(b) Some further explanation of the situation regarding class-X-licensed
build components would be helpful. In order to build, AFAIK, we need all
sorts of things, like dmake, epm, gcc, &c. These have to be present or
downloaded, true?
--
/tj/
RE: Draft IP Review Plan for OpenOffice
Posted by "Dennis E. Hamilton" <de...@acm.org>.
+1 on not downloading anything without consent.
-----Original Message-----
From: Rob Weir [mailto:robweir@apache.org]
Sent: Thursday, November 17, 2011 12:11
To: ooo-dev@incubator.apache.org
Subject: Re: Draft IP Review Plan for OpenOffice
On Thu, Nov 17, 2011 at 2:40 PM, Dave Fisher <da...@comcast.net> wrote:
>
> On Nov 17, 2011, at 11:16 AM, Rob Weir wrote:
>
>> I've consolidated and summarized the various bits of guidance we've
>> received on this list and on legal-discuss, and distill in down into
>> relevant guidance for this project. We don't need to all be experts
>> in this, but I think everyone contributing code needs to understand
>> the basics of what we may and may not do. Since I know that not
>> everyone has followed all the threads, I think it is worth bringing
>> this information together in one place, for easy reference.
>>
>> Since this is my interpretation of Apache policy, or even my
>> interpretation of someone else's interpretation, I'd ask you treat
>> this as a draft for now. But please do review, ask questions, and
>> point out any information that you believe is incorrect.
>>
>> https://cwiki.apache.org/confluence/display/OOOUSERS/IP+Plan+for+Apache+OpenOffice
>
> Thanks. This is a good reference.
>
> Here's an area where we either already know the answer or need clarification.
>
> We've recently had the subject of language packs with various licenses and copyrights including category X. If point 5 of Source Release:
>
>> 5. We may also have a build flag that permits the inclusion of weak copyleft, category-b licensed modules (e.g., MPL). When this flag is used, it could trigger the automated download of such modules. But this should require an explicit, informed choice from the user. They need to know that they are enabling the inclusion of non-Apache modules that have a different license.
>
> If this statement is rewritten for Binary releases to allow informed installation of a Language Pack whatever it's host, license and copyright might be - as long as on installation choices were clearly visible and the user explicitly opts in or out.
>
Good point. The parallelism here had not struck me before. I just
added it as a #3 under binary releases. I think, aside from any
license considerations, we should not be automatically downloading
anything without the user's consent.
> This same IP framework could be used for Extensions and Templates - an area in total limbo with no volunteers active.
>
> These three areas are important to users and users would benefit if the whole "ecosystem" co-operated.
>
> Regards,
> Dave
>
>
>>
>> Regards,
>>
>> -Rob
>
>
Re: Draft IP Review Plan for OpenOffice
Posted by Rob Weir <ro...@apache.org>.
On Thu, Nov 17, 2011 at 2:40 PM, Dave Fisher <da...@comcast.net> wrote:
>
> On Nov 17, 2011, at 11:16 AM, Rob Weir wrote:
>
>> I've consolidated and summarized the various bits of guidance we've
>> received on this list and on legal-discuss, and distill in down into
>> relevant guidance for this project. We don't need to all be experts
>> in this, but I think everyone contributing code needs to understand
>> the basics of what we may and may not do. Since I know that not
>> everyone has followed all the threads, I think it is worth bringing
>> this information together in one place, for easy reference.
>>
>> Since this is my interpretation of Apache policy, or even my
>> interpretation of someone else's interpretation, I'd ask you treat
>> this as a draft for now. But please do review, ask questions, and
>> point out any information that you believe is incorrect.
>>
>> https://cwiki.apache.org/confluence/display/OOOUSERS/IP+Plan+for+Apache+OpenOffice
>
> Thanks. This is a good reference.
>
> Here's an area where we either already know the answer or need clarification.
>
> We've recently had the subject of language packs with various licenses and copyrights including category X. If point 5 of Source Release:
>
>> 5. We may also have a build flag that permits the inclusion of weak copyleft, category-b licensed modules (e.g., MPL). When this flag is used, it could trigger the automated download of such modules. But this should require an explicit, informed choice from the user. They need to know that they are enabling the inclusion of non-Apache modules that have a different license.
>
> If this statement is rewritten for Binary releases to allow informed installation of a Language Pack whatever it's host, license and copyright might be - as long as on installation choices were clearly visible and the user explicitly opts in or out.
>
Good point. The parallelism here had not struck me before. I just
added it as a #3 under binary releases. I think, aside from any
license considerations, we should not be automatically downloading
anything without the user's consent.
> This same IP framework could be used for Extensions and Templates - an area in total limbo with no volunteers active.
>
> These three areas are important to users and users would benefit if the whole "ecosystem" co-operated.
>
> Regards,
> Dave
>
>
>>
>> Regards,
>>
>> -Rob
>
>
Re: Draft IP Review Plan for OpenOffice
Posted by Gianluca Turconi <pu...@letturefantastiche.com>.
In data 17 novembre 2011 alle ore 22:26:18, Rob Weir <ro...@apache.org>
ha scritto:
> I'm OK with that. This is what I was thinking of as #3 below. So
> saying, "You do not have a dictionary installed, would you like to see
> a list of 3rd party dictionaries?" is fine. You then can launch a
> browser or have an in-app extension browser. But we're not choosing
> among the alternatives. We're inviting the user to do this. Of
> course, a 3rd party could take AOO, modify it and constrain the
> choices further, bundle dictionaries, etc.
Are you talking about an after-installation wizard or something similar,
aren't you?
This means that AOOo wouldn't be a ready-to-use product just after the
installation. That's fine for individual installations.
However, what about network installations?
I think many IT admins *really* don't like users' installation of
add-ons... ;-)
Wouldn't it be better to have such procedure directly included into the
installation of the application?
There would be 2 options:
a) a normal installation (plain vanilla AOOo);
b) a custom Installation (vanilla AOOo + selected and downloadable
dictionaries, templates, everything else).
Just my 2 cents.
Regards,
Gianluca
--
Lettura gratuita o acquisto di libri e racconti di fantascienza, fantasy,
horror, noir, narrativa fantastica e tradizionale:
http://www.letturefantastiche.com/
Re: Draft IP Review Plan for OpenOffice
Posted by Rob Weir <ro...@apache.org>.
On Thu, Nov 17, 2011 at 4:13 PM, Dave Fisher <da...@comcast.net> wrote:
>
> On Nov 17, 2011, at 12:46 PM, Rob Weir wrote:
>
>> On Thu, Nov 17, 2011 at 3:30 PM, Dennis E. Hamilton
>> <de...@acm.org> wrote:
>>> Good point, Dave.
>>>
>>> I think one important consideration around this Opt-in provisions is also whether the download is something that is authenticated in some manner or is at the user's risk. I don't quite know how that gets dealt with. It may be that some arrangements for acquiring extensions and templates from third parties should be decoupled enough to avoid confusion that these are in any way authenticated for use with an Apache OpenOffice distribution. A separate downloading tool or even web page might be preferable for general sources of extensions and templates, something that takes overt attention to use.
>>>
>>
>> I see a few categories:
>>
>> 1) Downloads of AOO-released software that occurs automatically, in
>> the background. This should be rare, if at all. You could make the
>> argument of doing this with security patches, but industry best
>> practice is not to do this by default, but to allow user to opt-in to
>> automatic updates. This is not an issue for the project right now
>> because OOo doesn't do automatic updates.
>>
>> 2) Application-prompted downloads of additional modules. For example,
>> we notice that you are installed with Italian locale, and don't have a
>> spell checker, we raise a dialog and ask "Would you like to install
>> dictionary XXX"? We might be able to do this if we had some sort of
>> click through license for the user. But I don't think -- from a
>> policy perspective -- we want to do this. Why? What if there are two
>> different Italian dictionaries with different licenses, or the same
>> license but different authors? Which do we chose? I don't think we
>> want to be in the business of pre-selecting 3rd party partners for our
>> users.
>
> AOO prompted downloads of non-ASF hosted and Category X licensed additional modules is exactly what I think AOO should do. In your scenario we want languages to have multiple choices. If there are two (or five) then both (or all) are offered. I believe that we need to have a policy to allow 3rd parties to create plug-in Language Packs, Extension and Templates. To exclude this limits AOO to being a reference implementation. This is really another thread.
>
I'm OK with that. This is what I was thinking of as #3 below. So
saying, "You do not have a dictionary installed, would you like to see
a list of 3rd party dictionaries?" is fine. You then can launch a
browser or have an in-app extension browser. But we're not choosing
among the alternatives. We're inviting the user to do this. Of
course, a 3rd party could take AOO, modify it and constrain the
choices further, bundle dictionaries, etc.
>>
>> 3) Application-integrated browsing of extension repositories -- I
>> think this should should be fine, so long as the user can see and
>> agree to the underlying license.
>>
>> 4) User find and downloads an extension via a web browser or some
>> other means external to the OpenOffice app. Nothing we can really do
>> at that point. It is entirely in the user's control. They are
>> responsible for the license terms of whatever extension they download.
>>
>> 5) Third party customizes OpenOffice to do any of 1-3 above. Again,
>> it is outside of our control. We need to worry about what we control.
>>
>>
>>> This also raises some issues about how authentication is established for the desirable cases of easy opt-in. For some cases, I can see the distribution including a list of sources and keys that can be used to authenticate a download. (How that is authenticated is an interesting matter also. Some sort of anti-tampering provision may be needed, perhaps with an additional level of indirection -- so that it is not easy to tamper with the release: It may be that the list of authentic sources and keys is itself downloaded in a secure manner and kept current by the run-time, allowing for additions and revocations.)
>
> You are advocating that an ecosystem of Language Packs, Extensions, and Templates have two states - authenticated downloads and unauthenticated downloads. This is also another thread.
>
>
>>>
>>> There are some established procedures by which an Apache Release is authenticated and verifiable. This needs to be extended to binaries produced and distributed from the project. It will not be possible for individuals who make their own builds from source to counterfeit that authentication of their binaries. (They can offer their own authentication, of course. That's always possible, though impersonation of Apache OpenOffice is frowned-up, to say the least.)
>
> All Apache Release Candidates (binary and source) are signed by the Project Release Manager. If a PPMC member votes +1 to release they are affirming that they have checked the signatures on EVERY artifact. (A +1 vote affirms many other checks as well, RAT is our friend.) If any of the signatures are incorrect a PPMC member is EXPECTED to vote -1. In that case the artifacts are recreated and the VOTE is restarted. Projects will often script the signing of artifacts.
>
> Regards,
> Dave
>
>>> - Dennis
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Dave Fisher [mailto:dave2wave@comcast.net]
>>> Sent: Thursday, November 17, 2011 11:40
>>> To: ooo-dev@incubator.apache.org
>>> Subject: Re: Draft IP Review Plan for OpenOffice
>>>
>>>
>>> On Nov 17, 2011, at 11:16 AM, Rob Weir wrote:
>>>
>>> [ ... ]
>>>> https://cwiki.apache.org/confluence/display/OOOUSERS/IP+Plan+for+Apache+OpenOffice
>>>
>>> Thanks. This is a good reference.
>>>
>>> Here's an area where we either already know the answer or need clarification.
>>>
>>> We've recently had the subject of language packs with various licenses and copyrights including category X. If point 5 of Source Release:
>>>
>>>> 5. We may also have a build flag that permits the inclusion of weak copyleft, category-b licensed modules (e.g., MPL). When this flag is used, it could trigger the automated download of such modules. But this should require an explicit, informed choice from the user. They need to know that they are enabling the inclusion of non-Apache modules that have a different license.
>>>
>>> If this statement is rewritten for Binary releases to allow informed installation of a Language Pack whatever it's host, license and copyright might be - as long as on installation choices were clearly visible and the user explicitly opts in or out.
>>>
>>> This same IP framework could be used for Extensions and Templates - an area in total limbo with no volunteers active.
>>>
>>> These three areas are important to users and users would benefit if the whole "ecosystem" co-operated.
>>>
>>> Regards,
>>> Dave
>>>
>>>
>>>>
>>>> Regards,
>>>>
>>>> -Rob
>>>
>>>
>
>
Re: Draft IP Review Plan for OpenOffice
Posted by Dave Fisher <da...@comcast.net>.
On Nov 17, 2011, at 12:46 PM, Rob Weir wrote:
> On Thu, Nov 17, 2011 at 3:30 PM, Dennis E. Hamilton
> <de...@acm.org> wrote:
>> Good point, Dave.
>>
>> I think one important consideration around this Opt-in provisions is also whether the download is something that is authenticated in some manner or is at the user's risk. I don't quite know how that gets dealt with. It may be that some arrangements for acquiring extensions and templates from third parties should be decoupled enough to avoid confusion that these are in any way authenticated for use with an Apache OpenOffice distribution. A separate downloading tool or even web page might be preferable for general sources of extensions and templates, something that takes overt attention to use.
>>
>
> I see a few categories:
>
> 1) Downloads of AOO-released software that occurs automatically, in
> the background. This should be rare, if at all. You could make the
> argument of doing this with security patches, but industry best
> practice is not to do this by default, but to allow user to opt-in to
> automatic updates. This is not an issue for the project right now
> because OOo doesn't do automatic updates.
>
> 2) Application-prompted downloads of additional modules. For example,
> we notice that you are installed with Italian locale, and don't have a
> spell checker, we raise a dialog and ask "Would you like to install
> dictionary XXX"? We might be able to do this if we had some sort of
> click through license for the user. But I don't think -- from a
> policy perspective -- we want to do this. Why? What if there are two
> different Italian dictionaries with different licenses, or the same
> license but different authors? Which do we chose? I don't think we
> want to be in the business of pre-selecting 3rd party partners for our
> users.
AOO prompted downloads of non-ASF hosted and Category X licensed additional modules is exactly what I think AOO should do. In your scenario we want languages to have multiple choices. If there are two (or five) then both (or all) are offered. I believe that we need to have a policy to allow 3rd parties to create plug-in Language Packs, Extension and Templates. To exclude this limits AOO to being a reference implementation. This is really another thread.
>
> 3) Application-integrated browsing of extension repositories -- I
> think this should should be fine, so long as the user can see and
> agree to the underlying license.
>
> 4) User find and downloads an extension via a web browser or some
> other means external to the OpenOffice app. Nothing we can really do
> at that point. It is entirely in the user's control. They are
> responsible for the license terms of whatever extension they download.
>
> 5) Third party customizes OpenOffice to do any of 1-3 above. Again,
> it is outside of our control. We need to worry about what we control.
>
>
>> This also raises some issues about how authentication is established for the desirable cases of easy opt-in. For some cases, I can see the distribution including a list of sources and keys that can be used to authenticate a download. (How that is authenticated is an interesting matter also. Some sort of anti-tampering provision may be needed, perhaps with an additional level of indirection -- so that it is not easy to tamper with the release: It may be that the list of authentic sources and keys is itself downloaded in a secure manner and kept current by the run-time, allowing for additions and revocations.)
You are advocating that an ecosystem of Language Packs, Extensions, and Templates have two states - authenticated downloads and unauthenticated downloads. This is also another thread.
>>
>> There are some established procedures by which an Apache Release is authenticated and verifiable. This needs to be extended to binaries produced and distributed from the project. It will not be possible for individuals who make their own builds from source to counterfeit that authentication of their binaries. (They can offer their own authentication, of course. That's always possible, though impersonation of Apache OpenOffice is frowned-up, to say the least.)
All Apache Release Candidates (binary and source) are signed by the Project Release Manager. If a PPMC member votes +1 to release they are affirming that they have checked the signatures on EVERY artifact. (A +1 vote affirms many other checks as well, RAT is our friend.) If any of the signatures are incorrect a PPMC member is EXPECTED to vote -1. In that case the artifacts are recreated and the VOTE is restarted. Projects will often script the signing of artifacts.
Regards,
Dave
>> - Dennis
>>
>>
>>
>> -----Original Message-----
>> From: Dave Fisher [mailto:dave2wave@comcast.net]
>> Sent: Thursday, November 17, 2011 11:40
>> To: ooo-dev@incubator.apache.org
>> Subject: Re: Draft IP Review Plan for OpenOffice
>>
>>
>> On Nov 17, 2011, at 11:16 AM, Rob Weir wrote:
>>
>> [ ... ]
>>> https://cwiki.apache.org/confluence/display/OOOUSERS/IP+Plan+for+Apache+OpenOffice
>>
>> Thanks. This is a good reference.
>>
>> Here's an area where we either already know the answer or need clarification.
>>
>> We've recently had the subject of language packs with various licenses and copyrights including category X. If point 5 of Source Release:
>>
>>> 5. We may also have a build flag that permits the inclusion of weak copyleft, category-b licensed modules (e.g., MPL). When this flag is used, it could trigger the automated download of such modules. But this should require an explicit, informed choice from the user. They need to know that they are enabling the inclusion of non-Apache modules that have a different license.
>>
>> If this statement is rewritten for Binary releases to allow informed installation of a Language Pack whatever it's host, license and copyright might be - as long as on installation choices were clearly visible and the user explicitly opts in or out.
>>
>> This same IP framework could be used for Extensions and Templates - an area in total limbo with no volunteers active.
>>
>> These three areas are important to users and users would benefit if the whole "ecosystem" co-operated.
>>
>> Regards,
>> Dave
>>
>>
>>>
>>> Regards,
>>>
>>> -Rob
>>
>>
Re: Draft IP Review Plan for OpenOffice
Posted by Rob Weir <ro...@apache.org>.
On Thu, Nov 17, 2011 at 3:30 PM, Dennis E. Hamilton
<de...@acm.org> wrote:
> Good point, Dave.
>
> I think one important consideration around this Opt-in provisions is also whether the download is something that is authenticated in some manner or is at the user's risk. I don't quite know how that gets dealt with. It may be that some arrangements for acquiring extensions and templates from third parties should be decoupled enough to avoid confusion that these are in any way authenticated for use with an Apache OpenOffice distribution. A separate downloading tool or even web page might be preferable for general sources of extensions and templates, something that takes overt attention to use.
>
I see a few categories:
1) Downloads of AOO-released software that occurs automatically, in
the background. This should be rare, if at all. You could make the
argument of doing this with security patches, but industry best
practice is not to do this by default, but to allow user to opt-in to
automatic updates. This is not an issue for the project right now
because OOo doesn't do automatic updates.
2) Application-prompted downloads of additional modules. For example,
we notice that you are installed with Italian locale, and don't have a
spell checker, we raise a dialog and ask "Would you like to install
dictionary XXX"? We might be able to do this if we had some sort of
click through license for the user. But I don't think -- from a
policy perspective -- we want to do this. Why? What if there are two
different Italian dictionaries with different licenses, or the same
license but different authors? Which do we chose? I don't think we
want to be in the business of pre-selecting 3rd party partners for our
users.
3) Application-integrated browsing of extension repositories -- I
think this should should be fine, so long as the user can see and
agree to the underlying license.
4) User find and downloads an extension via a web browser or some
other means external to the OpenOffice app. Nothing we can really do
at that point. It is entirely in the user's control. They are
responsible for the license terms of whatever extension they download.
5) Third party customizes OpenOffice to do any of 1-3 above. Again,
it is outside of our control. We need to worry about what we control.
> This also raises some issues about how authentication is established for the desirable cases of easy opt-in. For some cases, I can see the distribution including a list of sources and keys that can be used to authenticate a download. (How that is authenticated is an interesting matter also. Some sort of anti-tampering provision may be needed, perhaps with an additional level of indirection -- so that it is not easy to tamper with the release: It may be that the list of authentic sources and keys is itself downloaded in a secure manner and kept current by the run-time, allowing for additions and revocations.)
>
> There are some established procedures by which an Apache Release is authenticated and verifiable. This needs to be extended to binaries produced and distributed from the project. It will not be possible for individuals who make their own builds from source to counterfeit that authentication of their binaries. (They can offer their own authentication, of course. That's always possible, though impersonation of Apache OpenOffice is frowned-up, to say the least.)
>
> - Dennis
>
>
>
> -----Original Message-----
> From: Dave Fisher [mailto:dave2wave@comcast.net]
> Sent: Thursday, November 17, 2011 11:40
> To: ooo-dev@incubator.apache.org
> Subject: Re: Draft IP Review Plan for OpenOffice
>
>
> On Nov 17, 2011, at 11:16 AM, Rob Weir wrote:
>
> [ ... ]
>> https://cwiki.apache.org/confluence/display/OOOUSERS/IP+Plan+for+Apache+OpenOffice
>
> Thanks. This is a good reference.
>
> Here's an area where we either already know the answer or need clarification.
>
> We've recently had the subject of language packs with various licenses and copyrights including category X. If point 5 of Source Release:
>
>> 5. We may also have a build flag that permits the inclusion of weak copyleft, category-b licensed modules (e.g., MPL). When this flag is used, it could trigger the automated download of such modules. But this should require an explicit, informed choice from the user. They need to know that they are enabling the inclusion of non-Apache modules that have a different license.
>
> If this statement is rewritten for Binary releases to allow informed installation of a Language Pack whatever it's host, license and copyright might be - as long as on installation choices were clearly visible and the user explicitly opts in or out.
>
> This same IP framework could be used for Extensions and Templates - an area in total limbo with no volunteers active.
>
> These three areas are important to users and users would benefit if the whole "ecosystem" co-operated.
>
> Regards,
> Dave
>
>
>>
>> Regards,
>>
>> -Rob
>
>
RE: Draft IP Review Plan for OpenOffice
Posted by "Dennis E. Hamilton" <de...@acm.org>.
Good point, Dave.
I think one important consideration around this Opt-in provisions is also whether the download is something that is authenticated in some manner or is at the user's risk. I don't quite know how that gets dealt with. It may be that some arrangements for acquiring extensions and templates from third parties should be decoupled enough to avoid confusion that these are in any way authenticated for use with an Apache OpenOffice distribution. A separate downloading tool or even web page might be preferable for general sources of extensions and templates, something that takes overt attention to use.
This also raises some issues about how authentication is established for the desirable cases of easy opt-in. For some cases, I can see the distribution including a list of sources and keys that can be used to authenticate a download. (How that is authenticated is an interesting matter also. Some sort of anti-tampering provision may be needed, perhaps with an additional level of indirection -- so that it is not easy to tamper with the release: It may be that the list of authentic sources and keys is itself downloaded in a secure manner and kept current by the run-time, allowing for additions and revocations.)
There are some established procedures by which an Apache Release is authenticated and verifiable. This needs to be extended to binaries produced and distributed from the project. It will not be possible for individuals who make their own builds from source to counterfeit that authentication of their binaries. (They can offer their own authentication, of course. That's always possible, though impersonation of Apache OpenOffice is frowned-up, to say the least.)
- Dennis
-----Original Message-----
From: Dave Fisher [mailto:dave2wave@comcast.net]
Sent: Thursday, November 17, 2011 11:40
To: ooo-dev@incubator.apache.org
Subject: Re: Draft IP Review Plan for OpenOffice
On Nov 17, 2011, at 11:16 AM, Rob Weir wrote:
[ ... ]
> https://cwiki.apache.org/confluence/display/OOOUSERS/IP+Plan+for+Apache+OpenOffice
Thanks. This is a good reference.
Here's an area where we either already know the answer or need clarification.
We've recently had the subject of language packs with various licenses and copyrights including category X. If point 5 of Source Release:
> 5. We may also have a build flag that permits the inclusion of weak copyleft, category-b licensed modules (e.g., MPL). When this flag is used, it could trigger the automated download of such modules. But this should require an explicit, informed choice from the user. They need to know that they are enabling the inclusion of non-Apache modules that have a different license.
If this statement is rewritten for Binary releases to allow informed installation of a Language Pack whatever it's host, license and copyright might be - as long as on installation choices were clearly visible and the user explicitly opts in or out.
This same IP framework could be used for Extensions and Templates - an area in total limbo with no volunteers active.
These three areas are important to users and users would benefit if the whole "ecosystem" co-operated.
Regards,
Dave
>
> Regards,
>
> -Rob
Re: Extensions and Templates [was: Re: Draft IP Review Plan for OpenOffice]
Posted by Rob Weir <ro...@apache.org>.
On Fri, Nov 18, 2011 at 11:36 AM, Reizinger Zoltán <zr...@hdsnet.hu> wrote:
> 2011.11.18. 17:19 keltezéssel, Rob Weir írta:
>>
>> On Fri, Nov 18, 2011 at 11:10 AM, Dave Fisher<da...@comcast.net>
>> wrote:
>>>
>>> On Nov 17, 2011, at 9:53 PM, Ariel Constenla-Haile wrote:
>>>
>>>> On Thu, Nov 17, 2011 at 11:40:25AM -0800, Dave Fisher wrote:
>>>>>
>>>>> If this statement is rewritten for Binary releases to allow informed
>>>>> installation of a Language Pack whatever it's host, license and
>>>>> copyright might be - as long as on installation choices were clearly
>>>>> visible and the user explicitly opts in or out.
>>>>>
>>>>> This same IP framework could be used for Extensions and Templates - an
>>>>> area in total limbo with no volunteers active.
>>>>
>>>> http://extensions.services.openoffice.org is down again (5:30 UTC).
>>>> Is this a problem with the host or a problem of lack of maintenance by
>>>> OOo side?
>>>> IIRC both http://extensions.services.openoffice.org and
>>>> http://templates.services.openoffice.org are hosted by the Oregon State
>>>> University Open Source Labs, and have been working bad all year long.
>>>
>>> I've discussed this with OSUOSL sysadmin.
>>>
>>> The servers are overloaded. So much so that the Nagios alerts were
>>> constant. They turned them off. Every so often varnish acts up and the
>>> machines lock.
>>>
>>> When this happens I have been the only one who emails support@osuosl.org
>>> - they are almost always responsive during business hours in their time zone
>>> - US Pacific.
>>>
>>> Both servers are customized Drupal stacks at different versions. There
>>> were people from Oracle working on upgrades. No one has volunteered to
>>> administrate these from the project.
>>>
>>> Since these servers host extensions and templates with all types of
>>> licenses they are not candidates for migration into the ASF.
>>>
>>> What should we do?
>>>
>> We could move to an entirely different model. Don't host extensions
>> at all. With SourceForge, github, Google Code, etc., there is really
>> no good reason why we need to have a single entity host all of the
>> extensions. It would be enough for us to have a browseable
>> catalog/registry of the extensions: name, description, category,
>> sreenshot, license and a URL to download.
>>
>> It would not be hard to scrape the existing extension side to form
>> this kind of category.
>
> This steps if it done, left out the existing users who accustomed to find
> extensions in these sites.
The URL for the catalog would not change. It would still be at
http://extensions.services.openoffice.org
> You needs to contact all template and extensions creators to host their
> stuff in other sites.
Correct. And in return for this one-time effort they would then
experience much more stable hosting.
> What will happen with Oracle created, provided templates, extensions (report
> builder, wiki publisher, ), all under SGA?
If something is under SGA to Apache, then we can store it in SVN and
release it like any other project release.
As you know, every Apache release goes out as a source tarball with an
optional binary release. This can then be downloaded via the mirrors.
But with some technologies there are other, additional ways of
distributed code. You might publish Java code on Maven Central. You
might package other code for inclusion in Linux distro catalogs, etc.
These are all things that volunteers can do after a release. I think
it would be the same here. If we have an extension that we want to
release via the normal release procedures, we can then list it in the
extension catalog. But it first needs to go through all of the normal
Apache release procedures.
-Rob
> Zoltan
>>
>> The license issue goes away, since there is no problem with having the
>> extension info hosted by Apache in a catalog of extensions.
>>
>> Load is not longer an issue, since the catalog can be very cheap --
>> static HTML if we want, generated from XML.
>>
>> I'd be willing to help with such an approach.
>>
>>
>> -Rob
>>
>>> Regards,
>>> Dave
>>>
>>>
>>>> Regards
>>>> --
>>>> Ariel Constenla-Haile
>>>> La Plata, Argentina
>>>
>
>
Re: Extensions and Templates [was: Re: Draft IP Review Plan for OpenOffice]
Posted by Reizinger Zoltán <zr...@hdsnet.hu>.
2011.11.18. 17:19 keltezéssel, Rob Weir írta:
> On Fri, Nov 18, 2011 at 11:10 AM, Dave Fisher<da...@comcast.net> wrote:
>> On Nov 17, 2011, at 9:53 PM, Ariel Constenla-Haile wrote:
>>
>>> On Thu, Nov 17, 2011 at 11:40:25AM -0800, Dave Fisher wrote:
>>>> If this statement is rewritten for Binary releases to allow informed
>>>> installation of a Language Pack whatever it's host, license and
>>>> copyright might be - as long as on installation choices were clearly
>>>> visible and the user explicitly opts in or out.
>>>>
>>>> This same IP framework could be used for Extensions and Templates - an
>>>> area in total limbo with no volunteers active.
>>> http://extensions.services.openoffice.org is down again (5:30 UTC).
>>> Is this a problem with the host or a problem of lack of maintenance by
>>> OOo side?
>>> IIRC both http://extensions.services.openoffice.org and
>>> http://templates.services.openoffice.org are hosted by the Oregon State
>>> University Open Source Labs, and have been working bad all year long.
>> I've discussed this with OSUOSL sysadmin.
>>
>> The servers are overloaded. So much so that the Nagios alerts were constant. They turned them off. Every so often varnish acts up and the machines lock.
>>
>> When this happens I have been the only one who emails support@osuosl.org - they are almost always responsive during business hours in their time zone - US Pacific.
>>
>> Both servers are customized Drupal stacks at different versions. There were people from Oracle working on upgrades. No one has volunteered to administrate these from the project.
>>
>> Since these servers host extensions and templates with all types of licenses they are not candidates for migration into the ASF.
>>
>> What should we do?
>>
> We could move to an entirely different model. Don't host extensions
> at all. With SourceForge, github, Google Code, etc., there is really
> no good reason why we need to have a single entity host all of the
> extensions. It would be enough for us to have a browseable
> catalog/registry of the extensions: name, description, category,
> sreenshot, license and a URL to download.
>
> It would not be hard to scrape the existing extension side to form
> this kind of category.
This steps if it done, left out the existing users who accustomed to
find extensions in these sites.
You needs to contact all template and extensions creators to host their
stuff in other sites.
What will happen with Oracle created, provided templates, extensions
(report builder, wiki publisher, ), all under SGA?
Zoltan
>
> The license issue goes away, since there is no problem with having the
> extension info hosted by Apache in a catalog of extensions.
>
> Load is not longer an issue, since the catalog can be very cheap --
> static HTML if we want, generated from XML.
>
> I'd be willing to help with such an approach.
>
>
> -Rob
>
>> Regards,
>> Dave
>>
>>
>>> Regards
>>> --
>>> Ariel Constenla-Haile
>>> La Plata, Argentina
>>
Re: Extensions and Templates [was: Re: Draft IP Review Plan for OpenOffice]
Posted by Rob Weir <ro...@apache.org>.
On Fri, Nov 18, 2011 at 11:36 AM, Dave Fisher <da...@comcast.net> wrote:
>
> On Nov 18, 2011, at 8:19 AM, Rob Weir wrote:
>
>> On Fri, Nov 18, 2011 at 11:10 AM, Dave Fisher <da...@comcast.net> wrote:
>>>
>>> On Nov 17, 2011, at 9:53 PM, Ariel Constenla-Haile wrote:
>>>
>>>> On Thu, Nov 17, 2011 at 11:40:25AM -0800, Dave Fisher wrote:
>>>>> If this statement is rewritten for Binary releases to allow informed
>>>>> installation of a Language Pack whatever it's host, license and
>>>>> copyright might be - as long as on installation choices were clearly
>>>>> visible and the user explicitly opts in or out.
>>>>>
>>>>> This same IP framework could be used for Extensions and Templates - an
>>>>> area in total limbo with no volunteers active.
>>>>
>>>> http://extensions.services.openoffice.org is down again (5:30 UTC).
>>>> Is this a problem with the host or a problem of lack of maintenance by
>>>> OOo side?
>>>> IIRC both http://extensions.services.openoffice.org and
>>>> http://templates.services.openoffice.org are hosted by the Oregon State
>>>> University Open Source Labs, and have been working bad all year long.
>>>
>>> I've discussed this with OSUOSL sysadmin.
>>>
>>> The servers are overloaded. So much so that the Nagios alerts were constant. They turned them off. Every so often varnish acts up and the machines lock.
>>>
>>> When this happens I have been the only one who emails support@osuosl.org - they are almost always responsive during business hours in their time zone - US Pacific.
>>>
>>> Both servers are customized Drupal stacks at different versions. There were people from Oracle working on upgrades. No one has volunteered to administrate these from the project.
>>>
>>> Since these servers host extensions and templates with all types of licenses they are not candidates for migration into the ASF.
>>>
>>> What should we do?
>>>
>>
>> We could move to an entirely different model. Don't host extensions
>> at all. With SourceForge, github, Google Code, etc., there is really
>> no good reason why we need to have a single entity host all of the
>> extensions. It would be enough for us to have a browseable
>> catalog/registry of the extensions: name, description, category,
>> sreenshot, license and a URL to download.
>
> author, copyright,...
>
>>
>> It would not be hard to scrape the existing extension side to form
>> this kind of category.
>
> Also, templates and language packs.
>
>>
>> The license issue goes away, since there is no problem with having the
>> extension info hosted by Apache in a catalog of extensions.
>>
>> Load is not longer an issue, since the catalog can be very cheap --
>> static HTML if we want, generated from XML.
>
> This "Plugin Catalog" XML would also be served so that AOO can consume it for extension, template, and language pack browsing in the UI.
>
> The URL of the plugin XML should be configurable in AOO. This nicely handles the institutional approved 3rd party issue.
>
>>
>> I'd be willing to help with such an approach.
>
> I like your plan, but there are further details like handling catalog submissions. These could be email to a special ML, but an automated approach might be better. 3rd parties may not react well to "arbitrary" delays.
>
Right. At first I thought we could just publish our XML schema for
the extension description and ask for extension authors to conform to
that. But that might not be reasonable. So maybe a web form that
collects the info, does simple validation and generates the XML,
sending it to the mailing list. If the rate of change for this data
is low, then PPMC can review and commit such changes. cron to
regenerate the catalog every hour or whatever.
> Regards,
> Dave
>
>
>>
>>
>> -Rob
>>
>>> Regards,
>>> Dave
>>>
>>>
>>>>
>>>> Regards
>>>> --
>>>> Ariel Constenla-Haile
>>>> La Plata, Argentina
>>>
>>>
>
>
Re: Extensions and Templates [was: Re: Draft IP Review Plan for OpenOffice]
Posted by Dave Fisher <da...@comcast.net>.
On Nov 18, 2011, at 8:19 AM, Rob Weir wrote:
> On Fri, Nov 18, 2011 at 11:10 AM, Dave Fisher <da...@comcast.net> wrote:
>>
>> On Nov 17, 2011, at 9:53 PM, Ariel Constenla-Haile wrote:
>>
>>> On Thu, Nov 17, 2011 at 11:40:25AM -0800, Dave Fisher wrote:
>>>> If this statement is rewritten for Binary releases to allow informed
>>>> installation of a Language Pack whatever it's host, license and
>>>> copyright might be - as long as on installation choices were clearly
>>>> visible and the user explicitly opts in or out.
>>>>
>>>> This same IP framework could be used for Extensions and Templates - an
>>>> area in total limbo with no volunteers active.
>>>
>>> http://extensions.services.openoffice.org is down again (5:30 UTC).
>>> Is this a problem with the host or a problem of lack of maintenance by
>>> OOo side?
>>> IIRC both http://extensions.services.openoffice.org and
>>> http://templates.services.openoffice.org are hosted by the Oregon State
>>> University Open Source Labs, and have been working bad all year long.
>>
>> I've discussed this with OSUOSL sysadmin.
>>
>> The servers are overloaded. So much so that the Nagios alerts were constant. They turned them off. Every so often varnish acts up and the machines lock.
>>
>> When this happens I have been the only one who emails support@osuosl.org - they are almost always responsive during business hours in their time zone - US Pacific.
>>
>> Both servers are customized Drupal stacks at different versions. There were people from Oracle working on upgrades. No one has volunteered to administrate these from the project.
>>
>> Since these servers host extensions and templates with all types of licenses they are not candidates for migration into the ASF.
>>
>> What should we do?
>>
>
> We could move to an entirely different model. Don't host extensions
> at all. With SourceForge, github, Google Code, etc., there is really
> no good reason why we need to have a single entity host all of the
> extensions. It would be enough for us to have a browseable
> catalog/registry of the extensions: name, description, category,
> sreenshot, license and a URL to download.
author, copyright,...
>
> It would not be hard to scrape the existing extension side to form
> this kind of category.
Also, templates and language packs.
>
> The license issue goes away, since there is no problem with having the
> extension info hosted by Apache in a catalog of extensions.
>
> Load is not longer an issue, since the catalog can be very cheap --
> static HTML if we want, generated from XML.
This "Plugin Catalog" XML would also be served so that AOO can consume it for extension, template, and language pack browsing in the UI.
The URL of the plugin XML should be configurable in AOO. This nicely handles the institutional approved 3rd party issue.
>
> I'd be willing to help with such an approach.
I like your plan, but there are further details like handling catalog submissions. These could be email to a special ML, but an automated approach might be better. 3rd parties may not react well to "arbitrary" delays.
Regards,
Dave
>
>
> -Rob
>
>> Regards,
>> Dave
>>
>>
>>>
>>> Regards
>>> --
>>> Ariel Constenla-Haile
>>> La Plata, Argentina
>>
>>
Re: Extensions and Templates [was: Re: Draft IP Review Plan for OpenOffice]
Posted by Rob Weir <ro...@apache.org>.
On Fri, Nov 18, 2011 at 11:10 AM, Dave Fisher <da...@comcast.net> wrote:
>
> On Nov 17, 2011, at 9:53 PM, Ariel Constenla-Haile wrote:
>
>> On Thu, Nov 17, 2011 at 11:40:25AM -0800, Dave Fisher wrote:
>>> If this statement is rewritten for Binary releases to allow informed
>>> installation of a Language Pack whatever it's host, license and
>>> copyright might be - as long as on installation choices were clearly
>>> visible and the user explicitly opts in or out.
>>>
>>> This same IP framework could be used for Extensions and Templates - an
>>> area in total limbo with no volunteers active.
>>
>> http://extensions.services.openoffice.org is down again (5:30 UTC).
>> Is this a problem with the host or a problem of lack of maintenance by
>> OOo side?
>> IIRC both http://extensions.services.openoffice.org and
>> http://templates.services.openoffice.org are hosted by the Oregon State
>> University Open Source Labs, and have been working bad all year long.
>
> I've discussed this with OSUOSL sysadmin.
>
> The servers are overloaded. So much so that the Nagios alerts were constant. They turned them off. Every so often varnish acts up and the machines lock.
>
> When this happens I have been the only one who emails support@osuosl.org - they are almost always responsive during business hours in their time zone - US Pacific.
>
> Both servers are customized Drupal stacks at different versions. There were people from Oracle working on upgrades. No one has volunteered to administrate these from the project.
>
> Since these servers host extensions and templates with all types of licenses they are not candidates for migration into the ASF.
>
> What should we do?
>
We could move to an entirely different model. Don't host extensions
at all. With SourceForge, github, Google Code, etc., there is really
no good reason why we need to have a single entity host all of the
extensions. It would be enough for us to have a browseable
catalog/registry of the extensions: name, description, category,
sreenshot, license and a URL to download.
It would not be hard to scrape the existing extension side to form
this kind of category.
The license issue goes away, since there is no problem with having the
extension info hosted by Apache in a catalog of extensions.
Load is not longer an issue, since the catalog can be very cheap --
static HTML if we want, generated from XML.
I'd be willing to help with such an approach.
-Rob
> Regards,
> Dave
>
>
>>
>> Regards
>> --
>> Ariel Constenla-Haile
>> La Plata, Argentina
>
>
Re: Extensions and Templates [was: Re: Draft IP Review Plan for OpenOffice]
Posted by FR web forum <oo...@free.fr>.
> http://extensions.services.openoffice.org is down again (5:30 UTC).
> http://templates.services.openoffice.org are hosted by the Oregon State
Both websites seem to be restarted.
Just few problem to loading page with error returns.
I don't know who thank but end users are grateful for that
Extensions and Templates [was: Re: Draft IP Review Plan for OpenOffice]
Posted by Dave Fisher <da...@comcast.net>.
On Nov 17, 2011, at 9:53 PM, Ariel Constenla-Haile wrote:
> On Thu, Nov 17, 2011 at 11:40:25AM -0800, Dave Fisher wrote:
>> If this statement is rewritten for Binary releases to allow informed
>> installation of a Language Pack whatever it's host, license and
>> copyright might be - as long as on installation choices were clearly
>> visible and the user explicitly opts in or out.
>>
>> This same IP framework could be used for Extensions and Templates - an
>> area in total limbo with no volunteers active.
>
> http://extensions.services.openoffice.org is down again (5:30 UTC).
> Is this a problem with the host or a problem of lack of maintenance by
> OOo side?
> IIRC both http://extensions.services.openoffice.org and
> http://templates.services.openoffice.org are hosted by the Oregon State
> University Open Source Labs, and have been working bad all year long.
I've discussed this with OSUOSL sysadmin.
The servers are overloaded. So much so that the Nagios alerts were constant. They turned them off. Every so often varnish acts up and the machines lock.
When this happens I have been the only one who emails support@osuosl.org - they are almost always responsive during business hours in their time zone - US Pacific.
Both servers are customized Drupal stacks at different versions. There were people from Oracle working on upgrades. No one has volunteered to administrate these from the project.
Since these servers host extensions and templates with all types of licenses they are not candidates for migration into the ASF.
What should we do?
Regards,
Dave
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
Re: Draft IP Review Plan for OpenOffice
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Thu, Nov 17, 2011 at 11:40:25AM -0800, Dave Fisher wrote:
> If this statement is rewritten for Binary releases to allow informed
> installation of a Language Pack whatever it's host, license and
> copyright might be - as long as on installation choices were clearly
> visible and the user explicitly opts in or out.
>
> This same IP framework could be used for Extensions and Templates - an
> area in total limbo with no volunteers active.
http://extensions.services.openoffice.org is down again (5:30 UTC).
Is this a problem with the host or a problem of lack of maintenance by
OOo side?
IIRC both http://extensions.services.openoffice.org and
http://templates.services.openoffice.org are hosted by the Oregon State
University Open Source Labs, and have been working bad all year long.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: Draft IP Review Plan for OpenOffice
Posted by Dave Fisher <da...@comcast.net>.
On Nov 17, 2011, at 11:16 AM, Rob Weir wrote:
> I've consolidated and summarized the various bits of guidance we've
> received on this list and on legal-discuss, and distill in down into
> relevant guidance for this project. We don't need to all be experts
> in this, but I think everyone contributing code needs to understand
> the basics of what we may and may not do. Since I know that not
> everyone has followed all the threads, I think it is worth bringing
> this information together in one place, for easy reference.
>
> Since this is my interpretation of Apache policy, or even my
> interpretation of someone else's interpretation, I'd ask you treat
> this as a draft for now. But please do review, ask questions, and
> point out any information that you believe is incorrect.
>
> https://cwiki.apache.org/confluence/display/OOOUSERS/IP+Plan+for+Apache+OpenOffice
Thanks. This is a good reference.
Here's an area where we either already know the answer or need clarification.
We've recently had the subject of language packs with various licenses and copyrights including category X. If point 5 of Source Release:
> 5. We may also have a build flag that permits the inclusion of weak copyleft, category-b licensed modules (e.g., MPL). When this flag is used, it could trigger the automated download of such modules. But this should require an explicit, informed choice from the user. They need to know that they are enabling the inclusion of non-Apache modules that have a different license.
If this statement is rewritten for Binary releases to allow informed installation of a Language Pack whatever it's host, license and copyright might be - as long as on installation choices were clearly visible and the user explicitly opts in or out.
This same IP framework could be used for Extensions and Templates - an area in total limbo with no volunteers active.
These three areas are important to users and users would benefit if the whole "ecosystem" co-operated.
Regards,
Dave
>
> Regards,
>
> -Rob