Re: spyparse - sparse reimplemented in Python

["Anderson Lizardo" <anderson.lizardo@gmail.com>]

On Sun, Jun 1, 2008 at 4:33 PM, Pavel Roskin <proski@gnu.org> wrote:
> On Fri, 2008-05-30 at 20:39 -0400, Anderson Lizardo wrote:
>
>> Some notes:
>>
>> - I decided to take a more pragmatic approach and start implementing
>> only those functions necessary for writing a test-*.c like backend
>> - For now I'm just doing a plain manual translation of the sparse C
>> code to Python, thus forcing me to read the entire sparse code (which
>> IMHO is a good thing for achieving reason (2))
>
> I'm surprised that you decided to relicense your work under GPLv2.
> Even though you are rewriting the code, it's still possible to argue
> that the original authors have rights to the code.
>
> It may be safer to use the original license, or you should make sure
> that the copyright holders are fine with what you are doing.

IANAL, but I had the impression that a copyright is applied to the
specific implementation of the work (and derivative works, such as
extensions or modifications to the original code) itself and not to
the algorithm. I presume my code is not a "derived work" from the
sparse code, even though I claim I'm "manually translating" to python
some parts of it. Unfortanely the "The Open Software License" does not
even describe what consists a "derivative work".

That said, I'd like to hear from some copyright holders about this
issue. I have plans to use my code with future projects that I'm sure
I'll not use OSL, and reading from
http://www.fsf.org/licensing/licenses/ I can see the OSL license is
GPL-imcompatible.

>> - Along the way I'm rewriting some code to become more OO-friendly
>> (with classes, methods etc.), therefore while the code is not finished
>> you will see a lot of mixed procedural and OO code
>
> I think it's a good idea, because sparse should be flexible.  It should
> be possible to change it for different coding standards.  A python
> implementation would be good, but it would also help if you provide
> detailed comments in the code.

Will do. But as I said, I just started coding it three days ago, so
consider the code in very bad shape right now. If I had decided to
publish the code only later, for sure it would be better commented,
but then I'd lose early comments as yours (which, specially for the
license issue, is very important).

BTW some comments are being purposedly ommited from the python code
because it fits better as a description above the function definition
and not on the calls. E.g.:

	// Tokenize the input stream
	token = tokenize(filename, fd, NULL, includepath);

But I'd like to first get more familiar with the sparse code and then
start adding detailed comments to the function definitions.

Thanks for the comments. Regards,
-- 
Anderson Lizardo