[kepler-dev] Proposed Use Cases for New Build System

[Timothy McPhillips]

Hi David,

Yes, let's all wait for feedback from everyone on how much work the  
licensing issues for compile-time dependencies would be to resolve  
before researching the other licenses.

Going over the Kepler/CORE build system use case proposals today  
sounds good, but here are few quick comments.  First, let's create a  
separate document listing a number of different options for how Kepler  
could conceivably depend on Ptolemy at compile time.  This will allow  
folks to point out pros and cons of each approach (and additional  
alternatives).  Second, let's work on separating out the high-level  
system functions from the implementation (and policy) proposals (the  
"wills" and "shoulds").  This will allow us to distinguish  
conversations about what functions and system characteristics we want  
to support from how one might achieve them, encourage others to  
propose different priorities, approaches, etc.  I think the current  
document can serve as seed and source material for these analyses.

Take the proposal to remove build- and run-time dependencies on  
environment variables, for example.  If we phrase the desideratum  
behind this as "support cross-platform, cross-tool (including multiple- 
IDE) development with minimal configuration", it will be clearer  
whether the ultimate goal is achievable and suggest what else would  
have to be done.

Thanks for doing this!

Tim

On Apr 14, 2008, at 6:23 AM, David Welker wrote:

> Hi Timothy,
>
> I did not work on licensing very much this weekend, although I now  
> have a new master spreadsheet that lists all 130 third-party jars  
> that Kepler theoretically depends on and I have started the  
> painstaking task of hunting down the licenses for the run-time  
> dependencies. I figured that it would be better to wait and see if  
> what we have already found is a big enough problem that we have to  
> restrict the licensing of the release to non-profit users. In some  
> sense, that may be the better way to go, as it will allow us to push  
> this release out the door and concentrate on defining a well-managed  
> core that we can easily license properly, rather than fighting to  
> get a whole lot of code BSD compliant that will be ejected from the  
> core in any case.
>
> Time is of the essence here, and if we make these licensing  
> restrictions a release blocker, we may delay this release  
> significantly. On the other hand, maybe it is not that much work to  
> get all this code, including portions that clearly will not be part  
> of the core in the future, BSD-compliant. I think we need to get  
> feedback on how much work it will be.
>
> Anyway, I have spent some time working on the use cases for our new  
> proposed build system. It is attached. I would love to get your  
> feedback on it today.
>
>
>
>
> <Proposed Use Cases - New Build System.doc>