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