incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <>
Subject Re: [DISCUSS]: hosting of source code that doesn't belong to the office directly
Date Tue, 06 Dec 2011 09:41:18 GMT
On 12/6/11 9:07 AM, Ross Gardler wrote:
> I've not seen any discussion of IP management in these extensions. All
> contributions would have to be made with an ICLA on file, all licenses
> would have to be acceptable and releases would have to be managed properly.
> Similarly development of the choose would be community led. Does the PPMC
> want to take on this responsibility? Will authors of these "extensions"
> want to work this way?

It should be obvious but nevertheless an interesting question! If 
somebody would like to develop an extension and would like to put it in 
our repo she/he has to be a committer. And all rules for normal 
contributions are valid.

The question for the release process is much more interesting.

In case of the NB plugin i see no problem to manage releases in an 
Apache conform way. Maybe we have to double check if it is allowed to 
host and develop a plugin for a CDDL 1.0/GPL v2 IDE or if developed 
plugins have any incompatible license restrictions.

If we want to develop extension here as well, our own extension 
repository becomes more important and would be the natural way to manage 
releases. At least from my point of view and probably not 100% Apache 

But we should think about the way people search and install extensions 
today. Most often they get notice about an extension somewhere, go to 
the extension repository and install it. Or they simply browse the ext 
repo and simply install and try an interesting one. Searching for a 
concrete ext is probably also a valid approach. The question here would 
be more how we could align such a development and release with Apache. A 
source release is probably less important and interesting for most of 
the users. But having the code available is of course important to reuse 
existing stuff for new extensions.

And more questions comes into my mind. Do we want to support extensions 
development under the umbrella of Apache? I think it is a good way to 
attract new developers, starting with extensions and do more and more 
work in the office code base in parallel. Often base code have to be 
changed, extended to make things possible via extensions.

Well we can also go the easier way and can move extension development to 
somewhere else but that is not optimal from my pov and we should try to 
bind developers to Apache. Make it interesting to work here in this 


> Sent from my mobile device, please forgive errors and brevity.
> On Dec 3, 2011 9:01 PM, "Andrea Pescetti"<>  wrote:
>> On 30/11/2011 Jürgen Schmidt wrote:
>>> On 11/30/11 1:31 PM, Rob Weir wrote:
>>>> Maybe just call it "extensions" ? This could be the root for
>>>> "standard extensions" that are produced by this project. Some might
>>>> be app dev related. But we might have other standard extensions in the
>>>> future, e.g., a CMIS extension using Apache Chemistry.
>>> i thought about "extensions" but in this particular case it is not an
>>> extension in the classical manner. But it is a developer tool for
>>> extensions and could be of course hosted there as well.
>> Then it would be clearer to use "extensions" for stuff that will
>> eventually be packaged into .oxt files, and "tools" or "devtools" for the
>> current use case, which is much more relaed to development than to
>> extensions. Not that I have a strong opinion on this; "extensions" just
>> seems potentially confusing for an editor plugin.
>> Regards,
>>   Andrea.

View raw message