Hi Ken,

How many methods are we talking about here? How many are 1 line, 2 line, 
have branches, etc? How many entire classes? Do we have some tools to 
work this out?

For simple 1 line methods, I think it's reasonable for our policy to be 
do nothing. This should certainly be the case for accessors, lazy 
initializers and other stuff we deem and can later justify as common place.

For long/complex methods, I think the answer might be to refactor these 
into new smaller methods. Slight of hand perhaps, but I think it gets 
the job done.

After dealing with the 1 liners and long/complex methods, how many are 
we left with?

I suspect the only way to deal with the remainder is for us to write 
unit tests, comments and then hire someone who has never touched Squeak 
before to write the methods.  They will have to convince the board and 
law foundation foundation that they have not touched Squeak before. 
It'll never be perfect but I think perfect is impossible.

- Zulq

Ken Causey wrote:
> Let me state my concerns another way as it seems I'm not being clear.
> 
> My concern is for the unknown person or entity some years from now who
> is considering adopting Squeak and sees something about the license
> history and has to have some basis for justifying that they have no
> reasonable fear of legal repercussions.
> 
> It seems to me that whatever we decide we have to clearly fully document
> this for years to come.
> 
> To make this more concrete it seems to me that the very first customer
> we have to please is the Software Freedom Law Center.  Do they not have
> some sort of formal policy on this?  If not, shouldn't they want to work
> with us to develop one?  This seems like a fundamental starting point at
> the very least.
> 
> Ken
> 
> 
> ------------------------------------------------------------------------
> 
>