kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo.bernardo@xxxxxxxxx>]

On Thu, Mar 26, 2015 at 11:56 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx>
wrote:

> On 3/26/2015 4:17 AM, Javier Serrano wrote:
> > On Thu, Mar 26, 2015 at 4:36 AM, Cirilo Bernardo
> > <cirilo.bernardo@xxxxxxxxx> 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