Here is an interesting page listing common open-source licensing:
http://developer.kde.org/documentation/licensing/licenses_summary.html
I'm still trying to read up on the major ones so that I can post my thoughts
on this conversation. (I'm not lurking on this issue, it just seems like
something that needs careful thought.)
I know we probably don't want to scare commercial developers. But we also
don't want them to be able to abuse our licensing leniency.
As part of the issue, I don't think we can get away without considering
licensing different components of the project separately.
The AOT is most valuable, because there isn't an open-source or even a
commercial equivalent of what ours does. We may even want to license
different parts of the AOT individually. Maybe modified BSD or MIT/X11 for
its JITing and AOTing ability...
...but something more restrictive, such as LGPL, for the x86(et all) ASM
stubbing ability, and the functionality (that hasn't been written yet) that
will implement the loopback 'extern' stubs we have talked about.
And the kernel itself, I just don't know... I would suggest going in the
direction of Linux, but there has been *alot* of debate over Linux's
licensing. But, if we plan on trying to port any tools or drivers, those
parts of our code will have to retain the same licensing, I believe.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers