Re: [Kicad-developers] thoughts on dependency on SISL library
On Fri, Mar 27, 2015 at 10:28:43PM -0500, inkblotter wrote: Does the AGPL allow me to modify the library and distribute the modified library? IANAL, yes as GPL does, mantaining the same license. AGPL is just a more web-aware copyleft license. -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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
Re: [Kicad-developers] thoughts on dependency on SISL library
Well spotted; so it's even less of an issue than I imagined it could be. I hope everyone agrees that the SISL library can become a dependency pending testing on MSWin (and Mac if someone can help me out). I imagine this won't happen for quite a few months yet since I need to work on many other issues including a proposal for managing the various 3D models and the inevitable refactor. I would need to do all that work before I would even start on the IGES exporter code itself; for the time being the IGES library will stand on its own fully capable of a proof-of-concept work but with no link whatsoever to KiCad until the 3D plugin or whatever we call it is done. - Cirilo On Fri, Mar 27, 2015 at 6:55 PM, Javier Serrano javier.serrano.par...@gmail.com wrote: On Fri, Mar 27, 2015 at 12:20 AM, Cirilo Bernardo cirilo.berna...@gmail.com wrote: My wording of the initial message must have been vague. AGPLv3 does not prohibit commercial use, but SINTEF as the copyright holder only allows AGPLv3 use if the application is not a commercial cloud service. Sorry to be a PITA Cirilo, but this is still not correct. Look at one example file, say [1]. It has a standard AGPL3 header. That means you are fully free to do with it all the things people do with AGPL-licensed files, including setting up a commercial cloud service. Then, after the standard AGPL3 header, they write this: Other Usage You can be released from the requirements of the license by purchasing a commercial license. Buying such a license is mandatory as soon as you develop commercial activities involving the SISL library *without* disclosing the source code of your own applications. Emphasis on without is mine. Also, the mentioning of commercial activities is superfluous in their sentence. *Any* activity, commercial or not, which breaches AGPL will need their permission. So people are completely free to set up a commercial cloud service using KiCad with SISL in it. They just have to provide users with an easy way to access all the sources of KiCad, including the SISL bits. This is the behaviour we all want (I guess) anyway, so all is good. Cheers, Javier [1] https://github.com/SINTEF-Geometry/SISL/blob/master/src/construct.c ___ 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
Re: [Kicad-developers] thoughts on dependency on SISL library
On Fri, Mar 27, 2015 at 8:55 AM, Javier Serrano javier.serrano.par...@gmail.com wrote: Other Usage You can be released from the requirements of the license by purchasing a commercial license. Buying such a license is mandatory as soon as you develop commercial activities involving the SISL library *without* disclosing the source code of your own applications. Just to add some more context which can help understand the situation: it is very common practice to have dual licensing schemes as a source of revenue. The rationale goes like this: I develop something good and license it under a free license. This license gives reassurance to many developers and they start using it. That makes the market bigger. Some users, though, might want to use the code without releasing the source of whatever they link with it. For these users, I set up a dual licensing scheme, whereby they can pay me in exchange of getting a version of the files (which only I have the right to generate) with a specific licensing agreement tailored to their needs. Now the question is, what free license should I use to begin with? Well, if I want to draw users who don't want to publish their code to the paying option I need to use the most aggressively copyleft license I can find. That today is the AGPL. It is stronger copyleft than GPL because it requests publishing the sources not only when distributing a binary but also when the binary runs in some server as a service. The above is not fully accurate legally, but I hope it gives some context to understand what SINTEF is trying to achieve, and therefore clarify how SISL can be used in KiCad. Cheers, Javier ___ 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
Re: [Kicad-developers] thoughts on dependency on SISL library
I’m not sure it fits all use cases I could think of, for example, let’s think you’re a board assembler/manufacturer, and you setup a site that accepts KiCad designs, and processes the files automatically via scripting to send you a cost estimation, and other information. Having SINTEF as AGPL could require them to publish their website scripts?, or their processing scripts?, it would be nice by the way, since other assemblers could have the chance to start doing the same, but… it’s probably an entry barrier for this ti happen. opinions?, Miguel Ángel Ajo On Friday, 27 de March de 2015 at 10:13, Cirilo Bernardo wrote: Well spotted; so it's even less of an issue than I imagined it could be. I hope everyone agrees that the SISL library can become a dependency pending testing on MSWin (and Mac if someone can help me out). I imagine this won't happen for quite a few months yet since I need to work on many other issues including a proposal for managing the various 3D models and the inevitable refactor. I would need to do all that work before I would even start on the IGES exporter code itself; for the time being the IGES library will stand on its own fully capable of a proof-of-concept work but with no link whatsoever to KiCad until the 3D plugin or whatever we call it is done. - Cirilo On Fri, Mar 27, 2015 at 6:55 PM, Javier Serrano javier.serrano.par...@gmail.com (mailto:javier.serrano.par...@gmail.com) wrote: On Fri, Mar 27, 2015 at 12:20 AM, Cirilo Bernardo cirilo.berna...@gmail.com (mailto:cirilo.berna...@gmail.com) wrote: My wording of the initial message must have been vague. AGPLv3 does not prohibit commercial use, but SINTEF as the copyright holder only allows AGPLv3 use if the application is not a commercial cloud service. Sorry to be a PITA Cirilo, but this is still not correct. Look at one example file, say [1]. It has a standard AGPL3 header. That means you are fully free to do with it all the things people do with AGPL-licensed files, including setting up a commercial cloud service. Then, after the standard AGPL3 header, they write this: Other Usage You can be released from the requirements of the license by purchasing a commercial license. Buying such a license is mandatory as soon as you develop commercial activities involving the SISL library *without* disclosing the source code of your own applications. Emphasis on without is mine. Also, the mentioning of commercial activities is superfluous in their sentence. *Any* activity, commercial or not, which breaches AGPL will need their permission. So people are completely free to set up a commercial cloud service using KiCad with SISL in it. They just have to provide users with an easy way to access all the sources of KiCad, including the SISL bits. This is the behaviour we all want (I guess) anyway, so all is good. Cheers, Javier [1] https://github.com/SINTEF-Geometry/SISL/blob/master/src/construct.c ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ 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
Re: [Kicad-developers] thoughts on dependency on SISL library
IANAL... On Fri, Mar 27, 2015 at 04:42:24PM +0100, Miguel Ángel Ajo wrote: I’m not sure it fits all use cases I could think of, for example, let’s think you’re a board assembler/manufacturer, and you setup a site that accepts KiCad designs, and processes the files automatically via scripting to send you a cost estimation, and other information. Having SINTEF as AGPL could require them to publish their website scripts?, or their processing scripts? I do not think so since AGPL do not automatically extend over external scripts... , it would be nice by the way, since other assemblers could have the chance to start doing the same, but… it’s probably an entry barrier for this ti happen. opinions?, See these already answered related questions: http://stackoverflow.com/questions/12165092/agpl-license-and-non-disclosed-user-scripts-like-blender-python-scripts http://programmers.stackexchange.com/questions/236184/do-i-need-to-publish-deployment-scripts-for-deploying-agpl-licensed-work-mongod bye -- Marco Ciampa I know a joke about UDP, but you might not get it. ++ | GNU/Linux User #78271 | | FSFE fellow #364 | ++ ___ 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
Re: [Kicad-developers] thoughts on dependency on SISL library
Hi, On 26.03.2015 11:21, Martijn Kuipers wrote: If the program is expressly designed to accept user requests and send responses over a network, then it meets these criteria. Common examples of programs that would fall into this category include web and mail servers, interactive web-based applications, and servers for games that are played online. If a program is not expressly designed to interact with a user through a network, but is being run in an environment where it happens to do so, then it does not fall into this category. For example, an application is not required to provide source merely because the user is running it over SSH, or a remote X session. I think that should be safe even when introducing a scripting host (which I plan to do later this year). Simon signature.asc Description: OpenPGP digital signature ___ 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
Re: [Kicad-developers] thoughts on dependency on SISL library
Viva Miguel, We should be fine, from https://www.gnu.org/licenses/gpl-faq.html#v3Notwithstanding: https://www.gnu.org/licenses/gpl-faq.html#v3Notwithstanding: In AGPLv3, what counts as “interacting with [the software] remotely through a computer network?” If the program is expressly designed to accept user requests and send responses over a network, then it meets these criteria. Common examples of programs that would fall into this category include web and mail servers, interactive web-based applications, and servers for games that are played online. If a program is not expressly designed to interact with a user through a network, but is being run in an environment where it happens to do so, then it does not fall into this category. For example, an application is not required to provide source merely because the user is running it over SSH, or a remote X session. BTW, I think it was an extremely generous parting gift from Dick Hollenbeck to allow the project-lead (or Jean Pierre) to relicense the code he provided under GPLv3. Regards, Martijn On 26 Mar 2015, at 09:48, Miguel Ángel Ajo majop...@redhat.com wrote: Not being able to use it for cloud services because of AGPL3+ (I haven’t looked at the license, I say it per your comments, cirilo) means that people could not use Kicad scripting for automating the processing for manufacturing of Kicad files (as an example) without publishing their scripts (I guess). And that’s not necessarily a good thing. Miguel Ángel Ajo On Thursday, 26 de March de 2015 at 9:17, Javier Serrano wrote: On Thu, Mar 26, 2015 at 4:36 AM, Cirilo Bernardo cirilo.berna...@gmail.com mailto: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 PS 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. 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. There is still the misleading COPYRIGHT.txt in the root of the KiCad sources, which I think should just be removed. This is important, and I hope it can be done before the stable release. Cheers, Javier ___ Mailing list: https://launchpad.net/~kicad-developers https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net mailto:kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp https://help.launchpad.net/ListHelp ___ 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 ___ 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
Re: [Kicad-developers] thoughts on dependency on SISL library
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 PS 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. 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. There is still the misleading COPYRIGHT.txt in the root of the KiCad sources, which I think should just be removed. This is important, and I hope it can be done before the stable release. Cheers, Javier ___ 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
Re: [Kicad-developers] thoughts on dependency on SISL library
Not being able to use it for cloud services because of AGPL3+ (I haven’t looked at the license, I say it per your comments, cirilo) means that people could not use Kicad scripting for automating the processing for manufacturing of Kicad files (as an example) without publishing their scripts (I guess). And that’s not necessarily a good thing. Miguel Ángel Ajo On Thursday, 26 de March de 2015 at 9:17, Javier Serrano wrote: On Thu, Mar 26, 2015 at 4:36 AM, Cirilo Bernardo cirilo.berna...@gmail.com (mailto: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 PS 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. 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. There is still the misleading COPYRIGHT.txt in the root of the KiCad sources, which I think should just be removed. This is important, and I hope it can be done before the stable release. Cheers, Javier ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net (mailto:kicad-developers@lists.launchpad.net) Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp ___ 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
Re: [Kicad-developers] thoughts on dependency on SISL library
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 PS 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. 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. There is still the misleading COPYRIGHT.txt in the root of the KiCad sources, which I think should just be removed. This is important, and I hope it can be done before the stable release. I believe it's a fairly common practice to include a copy of the GPL in a project's source code so I will remove the GPL2 only part that Dick added to the top of the license file if that is not objectionable. I'm assuming that no other modifications have been made to the GPL license part of the file. Cheers, Wayne Cheers, Javier ___ 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 ___ 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
Re: [Kicad-developers] thoughts on dependency on SISL library
On Thu, Mar 26, 2015 at 4:58 PM, Wayne Stambaugh stambau...@gmail.com wrote: I think anyone who provides KiCad as a service should make the KiCad source available. It seems to me that the GPL2+ should cover that as well since I'm guessing any service would be using a modified version of the KiCad source directly. If my understanding is right, the perception that GPL does not cover that case was the very reason to develop AGPL in the first place. I'm not saying AGPL does a good job at it. I am not qualified for that. But I think that was the aim of the people who drafted it. Cheers, Javier ___ 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
Re: [Kicad-developers] thoughts on dependency on SISL library
https://www.gnu.org/licenses/why-affero-gpl.html GNU's own explanation. ___ 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
Re: [Kicad-developers] thoughts on dependency on SISL library
On Thu, Mar 26, 2015 at 1:56 PM, Wayne Stambaugh stambau...@gmail.com wrote: I believe it's a fairly common practice to include a copy of the GPL in a project's source code so I will remove the GPL2 only part that Dick added to the top of the license file if that is not objectionable. I'm assuming that no other modifications have been made to the GPL license part of the file. I am afraid that would still be misleading since we have both GPL2+ and GPL3+ files in the project. Why have the text of GPL2 in COPYRIGHT.txt, therefore giving the false impression that the whole project is GPL2? I would like to join Martijn in thanking Dick for his generosity, not only for explicitly allowing to license his files under GPL3 with a message to the list, but for including the or later in all the headers of the many files he committed through the years. When you say or later you are saying that you are allowing the maintainers of GPL (i.e. the FSF) to have quite some impact on how the fruit of your hard work can be used in the future. This is a hard decision, especially for people who do not necessarily share all of the values and agenda of the FSF, but it's proven to be very good for projects. The or later gives flexibility for the future. It allows linking in code which is licensed using new versions of the GPL, which get released in response to a changing legal environment or perceived shortcomings in older versions. So using or later is generous, and I believe it's also the right thing to do so far as the project is concerned. Thanks all, Javier ___ 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
Re: [Kicad-developers] thoughts on dependency on SISL library
On 3/26/2015 9:58 AM, Javier Serrano wrote: On Thu, Mar 26, 2015 at 1:56 PM, Wayne Stambaugh stambau...@gmail.com wrote: I believe it's a fairly common practice to include a copy of the GPL in a project's source code so I will remove the GPL2 only part that Dick added to the top of the license file if that is not objectionable. I'm assuming that no other modifications have been made to the GPL license part of the file. I am afraid that would still be misleading since we have both GPL2+ and GPL3+ files in the project. Why have the text of GPL2 in COPYRIGHT.txt, therefore giving the false impression that the whole project is GPL2? Makes sense to me. I will remove COPYRIGHT.txt from the KiCad source when I get a chance. I would like to join Martijn in thanking Dick for his generosity, not only for explicitly allowing to license his files under GPL3 with a message to the list, but for including the or later in all the headers of the many files he committed through the years. When you say or later you are saying that you are allowing the maintainers of GPL (i.e. the FSF) to have quite some impact on how the fruit of your hard work can be used in the future. This is a hard decision, especially for people who do not necessarily share all of the values and agenda of the FSF, but it's proven to be very good for projects. The or later gives flexibility for the future. It allows linking in code which is licensed using new versions of the GPL, which get released in response to a changing legal environment or perceived shortcomings in older versions. So using or later is generous, and I believe it's also the right thing to do so far as the project is concerned. Thanks to everyone who has chosen to commit code to KiCad under the GPL2+ or later license. Your generosity is appreciated. I know from my own experience that it is not always easy to place your trust in an organization that you may not know much about. So far the FSF has proven they have the interest of developers in mind which has allowed projects like KiCad to flourish. Let's hope they continue to work in good faith. Wayne Thanks all, Javier ___ 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
Re: [Kicad-developers] thoughts on dependency on SISL library
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 PS 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
Re: [Kicad-developers] thoughts on dependency on SISL library
On Fri, Mar 27, 2015 at 1:34 AM, Javier Serrano javier.serrano.par...@gmail.com wrote: On Thu, Mar 26, 2015 at 1:56 PM, Wayne Stambaugh stambau...@gmail.com wrote: 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. My understanding about the AGPL3+ thing: it looks to me like the only effect (which is significant and therefore needs to be officially decided) would be that it would be illegal to provide KiCad as a service (i.e. running in some server instead of in the local host of the user) *without* providing access to the KiCad sources as well. I personally don't see anything wrong with that in principle. There might also be complications of some kind in the future arising from the fact that we would then need to keep an eye not only on future versions of the GPL but also on future versions of the AGPL. And there is also some difficult-to-evaluate risk in the fact that AGPL is a much less used license than GPL, so much less challenged and proven as well. The only real limitation is that if you're providing KiCad as a commercial cloud service then a licensing agreement has to be negotiated with SINTEF; this is not an issue for any KiCad user I know of and these licenses must be obtained on a case-by-case basis anyway so they are no concern of the KiCad project team, only of the operators who may want to offer a cloud service. If anyone wants to do that and doesn't want to negotiate a license then they can disable the compilation of any IGES code, or if the code has been designed to operate without the NURBS code then build without the SISL library. Even if you're using KiCad in an internal cloud service you would not require a license since you're not offering a commercial cloud service. - 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
Re: [Kicad-developers] thoughts on dependency on SISL library
On 3/26/2015 3:20 PM, Mark Roszko wrote: https://www.gnu.org/licenses/why-affero-gpl.html GNU's own explanation. Thanks for the reference. This definitely makes things a bit clearer. Since this is directly from the FSF and gnu.org, I feel better about any difference between the licenses. ___ 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
Re: [Kicad-developers] thoughts on dependency on SISL library
On 3/26/2015 10:34 AM, Javier Serrano wrote: On Thu, Mar 26, 2015 at 1:56 PM, Wayne Stambaugh stambau...@gmail.com wrote: 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. My understanding about the AGPL3+ thing: it looks to me like the only effect (which is significant and therefore needs to be officially decided) would be that it would be illegal to provide KiCad as a service (i.e. running in some server instead of in the local host of the user) *without* providing access to the KiCad sources as well. I personally don't see anything wrong with that in principle. There might also be complications of some kind in the future arising from the fact that we would then need to keep an eye not only on future versions of the GPL but also on future versions of the AGPL. And there is also some difficult-to-evaluate risk in the fact that AGPL is a much less used license than GPL, so much less challenged and proven as well. Cheers, Javier I think anyone who provides KiCad as a service should make the KiCad source available. It seems to me that the GPL2+ should cover that as well since I'm guessing any service would be using a modified version of the KiCad source directly. However, I personally don't have an issue with your description of the AGPL3+. Does anyone else object to including this is KiCad for licensing reasons? As far as licensing compatibility and risk we are still bound by the wxWidgets and Boost licenses so we will always have some licensing unknowns as far as changes and legal validation even though they are more permissive licenses. Cheers, Wayne ___ 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
