[os-infrastructure] Closed source components

[Chris Clark]

RE email trail below and keeping closed source away from the public.

 From a discussion I had with Andrew, for the create source (Ingres) tar 
ball from main scripts/process we have a mechanism that :

    * filters whole directories
    * filters files from directories that are not filtered by above


How this would work for a sync process would probably be non-trivial but 
do-able. If we moved whole sale to a new scs we may be able to use 
permissions in the scs to prevent access to these closed source 
components (but we are no where near a migration yet, and I'm not sure 
if [for example] svn  has this kind of granularity).

So for modules, this is a solvable (and partially solved today) problem.

The tricky part is when we have closed source mixed in the public facing 
code (possibly like the B1 code). One answer to this is a hard and 
simple rule of, "no closed source in public facing code." This would 
mean we would have calls to closed source in the public facing code 
(probably in ifdefs) with the closed source contained in a filtered 
module, this would have to mean that all closed source code would need 
to be plug-able. I'm not sure if there are any other options.

If we went this route, ingres!main could be filtered/sync'd and made 
available in the public scs (say svn), which is pretty much what both 
Proposal 1 and 3 at http://community.ingres.com/wiki/Community_Model is 
about (but doesn't talk about how the sync works).

Personally I'm now leaning towards Proposal 1 which would allow us 
(and/or the community) to move to Proposal 3 if/once the community 
decides they need to have features that we Ingres Corp will never want 
in the enterprise version. This is a big change for me as I was very 
much in favor of the buffer approach. With minor changes to how we 
handle closed source pieces I think we can do without the buffer. The 
community can benefit from being closer to the enterprise code as they 
do not have to worry about integrations unless they feel the need to 
diverge (once they diverge, they have to handle the integration problem).

Again this is for Ingres, and not for OpenROAD.

Chris



On 6/30/2008 6:59 AM, Joe Abbate wrote:
> Hi Steve,
>
> Stephen Ball wrote:
>> I'm figuring "trunk" may not necessarily mean "all of main", if there
>> were any non open source parts presumably we would exclude them from
>> Subversion. But don't we have that issue no matter what model we choose?
>>   
>
> The question in my mind is how do you define those "parts".  If it's 
> something easily restricted to a given set of Piccolo directories, 
> then may be fairly easy.  If I understand correctly, that's how 
> OpenROAD could release its 4GL code as open source without releasing 
> the 3GL pieces which for the most part live in other Piccolo 
> directories.  We similarly "removed" spatials from Ingres DBMS open 
> source, because most of it was in common!adf!ads.  However, if you 
> look at change 469243 where you removed B1 security support, you had 
> to touch (edit) 380 files all over the source tree.  Conversely, 
> although I don't know much about Project D, I'm guessing that would 
> affect various areas of PSF and QEF.  There is therefore a high 
> likelihood that changes will affect existing directories and existing 
> files, i.e., not neatly separable "parts".