On Thu, Mar 26, 2015 at 11:56 PM, Wayne Stambaugh <stambau...@gmail.com> wrote:
> On 3/26/2015 4:17 AM, Javier Serrano wrote: > > On Thu, Mar 26, 2015 at 4:36 AM, Cirilo Bernardo > > <cirilo.berna...@gmail.com> wrote: > > [ snip ] > >> The only really tricky part comes from the 'v3' bit - according to the > FSF > >> the AGPLv3 is not compatible with GPL2, and not even compatible with > >> GPLv3 but OK to mix with GPLv3 (whatever that means - I can already > >> hear some lawyers laughing). > > > > [ IANAL, please take the following as the opinion of a non-expert. ] > > > > This is why the '+' (i.e. the "or-later") in "GPL2+" is really > > important. The KiCad sources are, to the best of my knowledge, GPL2+ > > (most) and GPL3+ (the P&S router). That means that the mix is > > effectively GPL3+. SISL seems to be AGPL3+. I see no incompatibility > > (see section 13 of both licenses), but mixing in AGPL3+ code is a step > > in the "stronger copyleft" direction. This is a strategic decision to > > be taken, IMHO by the project leader. > > Mixing licenses is always tricky business. You risk licensing yourself > into a corner. I am not an expert on licensing and I would never > pretend otherwise. That being said, if the AGPLv3 license prevents us > from using the SISL source for cloud services as others have suggested > then I cannot not accept that. I think making KiCad into some type of > collaborative online service like google docs would be something that is > worthwhile. If this is not the case, then I have less of an issue. > > If anyone wants to offer a cloud service to the general public then they have to negotiate a license or else not include SISL. Since the IGES code is not too complex yet (only 14k lines of code) I can refactor it so that SISL can be dropped. This will mean that (1) the data in NURBS objects cannot be checked or evaluated and (b) the routines which create a board model will require a little extra code to avoid using SISL. This design decision is best made now but my preference is to use SISL and anyone who want to offer a cloud service can do the extra work or drop IGES export. > > > >> Any thoughts on eventually having SISL as a dependency? What's the > >> current status of licensing of KiCad source modules? I can remove > >> the SISL dependency but this will cripple the IGES code by removing > >> the ability to check the validity of some structures within an input > file. > > Assuming the licensing is not an issue (which appears not to be the > case), there are substantial dependency related issues that have to be > addressed before I would accept a new dependency. SISL must build and > install on all three platforms supported by KiCad using the normal `make > && make install` commands. Whether autotools or CMake or some other > configuration tool is used doesn't matter as long as it is supported on > all three platforms. I will not allow another dependency build (like > boost) to be added to the KiCad source. The dependency build code that > we currently have will be removed after the stable release. > > SISL uses cmake and runs under a variety of systems; I'll do a build on MSYS2/MinGW to confirm everything works. It should work fine on OSX but I might need some help checking things there since I don't have a Mac. - Cirilo
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp