I'm still waiting for our friends at CERN for an answer on library licensing. We are leaning towards CC-SA with the use exception clause. I turning out to be the longest time ever to write a single sentence. ;) I'm not sure this license will be applicable to script generated models.
On 2/25/2017 8:23 PM, Cirilo Bernardo wrote: > GPL scripts with no restrictions on the generated models is perfect. > > - Cirilo > > On Sun, Feb 26, 2017 at 12:02 PM, Oliver Walters > <[email protected]> wrote: >> The licence on the legacy models I am unsure about. >> >> Maurice, Rene, Jan and myself have been discussing the licence for models >> that we create (script). It is GPL with an explicit exception stating that >> models can be freely used and shared without normal GPL requirements. >> >> If you look at Maurice's scripts (https://GitHub.com/easyw) he has already >> implemented this. >> >> Oliver >> >> >> On 26 Feb 2017 11:25 AM, "Cirilo Bernardo" <[email protected]> >> wrote: >> >> I think one repository for the old VRML models, another for MCAD >> models, and a third for scripts. In cases where an MCAD model has a >> corresponding VRML model which has been specially crafted to look >> better in the 3D viewer, that VRML model should be alongside the MCAD >> model and in the MCAD directory. I think this scheme gives us a path >> to eventually deprecate the old VRML models as we build up >> replacements on the MCAD side. >> >> Package maintainers can decide what to offer on each platform and sort >> out the dependencies. I imagine the old VRML will be included simply >> because so many people use it; MCAD+VRML would probably be a separate >> option due to the sheer volume, and some package maintainers might >> decide to offer the scripts instead and pull in all the dependencies. >> At any rate, the scripting option is definitely not for beginners. >> >> There is also the issue of licenses for the models. A few users have >> expressed concerns that some models are licensed under GPL (whatever >> that means for something which is not software) but in general people >> are concerned that kicad models may be of no value to them because (a) >> licensing might be mixed and difficult to determine and (b) some >> licenses may prevent them from using models in their commercial >> projects. >> >> - Cirilo >> >> On Sun, Feb 26, 2017 at 10:02 AM, Oliver Walters >> <[email protected]> wrote: >>> Cirilo, >>> >>> Some great ideas there - I was being more than slightly facetious by >>> suggesting it would be the work of a weekend :) >>> >>> Should we have separate repositories for MCAD models and wrl? And a third >>> for scripts? >>> >>> >>> On 26 Feb 2017 08:31, "Cirilo Bernardo" <[email protected]> wrote: >>> >>> On Sat, Feb 25, 2017 at 3:53 PM, Oliver Walters >>> <[email protected]> wrote: >>>> Simon, >>>> >>>> Are you saying we should host the models and provide them on demand? >>>> >>>> I would agree. This way we can provide models independent of the source >>>> (scripts, etc). >>>> >>>> It also makes it way easier for users. >>>> >>>> I like the idea of a KiCad-integrated model wizard but I'll leave that >>>> for >>>> Cirilo to code when he has a free weekend. >>>> >>> >>> I'm sure it would take more than a weekend. Whatever your solution for >>> now, I think it is important to separate the old Wings3D/VRML models >>> from any models generated from MCAD. Better still, if there can be some >>> text file associated with each STEP/VRML pair (or script) stating the >>> author, source of data, and whether or not the mechanically important >>> dimensions were verified (and by who). Such text files with a 'checked by' >>> entry could also be useful for footprints and schematic symbols as well. >>> >>> I'll put scripted STEP model generation on my list of things to do, but >>> given that existing bugs have the highest priority and then the PCB API >>> after that, I have no idea when I'll get around to it. For me the ideal >>> scripting solution would consist of (a) compiled C++ parametric tools >>> (b) python scripts (c) XML schema for describing the scripts and how to >>> invoke them (d) GUI for searching the XML files and magically creating >>> the menus for controlling parameters on the selected XML file. It's an >>> awful lot of work for what would be only a small improvement on Maurice's >>> current tools, but once (a) and (b) are done we will at least be in a >>> position to ship scripts rather than models and we could always have >>> some hard-coded tool for selecting and executing scripts in the short >>> term. >>> >>> - Cirilo >>> >>>> I'll let all this percolate. Thanks for the input. >>>> >>>> On 25 Feb 2017 1:41 PM, "Simon Wells" <[email protected]> wrote: >>>>> >>>>> i don't see why on-install and if it can be done at install time why >>>>> not just do it on-demand of the model... if its slow cache but still >>>>> ondemand, >>>>> >>>>> providing models that we gen will likely require a full stack of >>>>> development as git/github isn't really ideal for stuff like this >>>>> >>>>> On 25 February 2017 at 15:15, Oliver Walters >>>>> <[email protected]> wrote: >>>>>> I personally find the idea of on-demand model creation appealing. >>>>>> >>>>>> I think that if we are to "promote" this as the preferred method, it >>>>>> should >>>>>> be improved through simplification and consolidation. >>>>>> >>>>>> Scripted models have only been added in the last week. Most of the >>>>>> models >>>>>> are legacy (poor quality wrl made in wings etc). There are also now a >>>>>> lot of >>>>>> models that have been generated via the spreadsheet functionality in >>>>>> Freecad. >>>>>> >>>>>> So already there are two competing scripting methods. What I want to >>>>>> achieve >>>>>> is a simplified and unified library structure. >>>>>> >>>>>> I realise that due to file size this is not so practical for the 3D >>>>>> models. >>>>>> >>>>>> Perhaps a good idea is to dictate a scripting architecture that allows >>>>>> us to >>>>>> be somewhat forward-compatible, and not actually provide 3D models. >>>>>> >>>>>> The current scripts could be made more generic and "publish" their >>>>>> parameters in such a way that an external tool can have some >>>>>> introspection >>>>>> of the scripts. Much like the python footprint wizards currently work >>>>>> in >>>>>> KiCad. >>>>>> >>>>>> Then, a "helper" script can parse the generator scripts, and the user >>>>>> can >>>>>> select which models to generate. This could even be run on KiCad >>>>>> install. >>>>>> >>>>>> e.g. a list of checkboxes to install "all JST connectors" or "R0603". >>>>>> >>>>>> Alternatively, we host all the generated models, and provide a >>>>>> download >>>>>> tool >>>>>> which downloads models as required. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> On 25 Feb 2017 10:48 AM, "Cirilo Bernardo" <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Hi Oliver, >>>>>> >>>>>> The scripts will easily generate many GB of data in time and for me >>>>>> it's >>>>>> not >>>>>> reasonable to download that amount of data. I think new users should >>>>>> simply >>>>>> learn to read documentation and generate the models rather than >>>>>> downloading >>>>>> them. Package maintainers can automatically run the scripts. Users >>>>>> will >>>>>> still >>>>>> have access to all the old VRML models and if they want to use the >>>>>> newer >>>>>> models, especially the STEP+VRML models, they should learn to set up >>>>>> the >>>>>> required tools. As I said, this requires a lot more thought. >>>>>> >>>>>> I suspect we can indeed develop our own parametric 3D modeling tools >>>>>> for >>>>>> KiCad based on OCE and provide a scheme to specify good material >>>>>> appearances for the VRML export as Maurice's tools do, but it's really >>>>>> a >>>>>> question of time and planning. Having scripts available in the >>>>>> official >>>>>> repo >>>>>> I think is a good start and will keep the expert users happy until >>>>>> someone >>>>>> gets around to creating these specialised tools for kicad. >>>>>> >>>>>> - Cirilo >>>>>> >>>>>> >>>>>> On Sat, Feb 25, 2017 at 10:10 AM, Oliver Walters >>>>>> <[email protected]> wrote: >>>>>>> Cirilo, >>>>>>> >>>>>>> Unless we made script generation of models completely idiot proof, I >>>>>>> think >>>>>>> that requiring another niche toolset would only serve to increase the >>>>>>> already high barrier to entry for new users. >>>>>>> >>>>>>> The 3D scripts require, currently: >>>>>>> >>>>>>> - Freecad >>>>>>> - cadquery plugin >>>>>>> >>>>>>> Plus the scripts themselves are a bit opaque to use. >>>>>>> >>>>>>> I think that if we are going to distribute recipes for models rather >>>>>>> than >>>>>>> the models themselves, that should be integrated into KiCad? >>>>>>> >>>>>>> You're the expert on the 3D code, is there any possibility that we >>>>>>> could >>>>>>> have a 3D wizard that operates in a similar way to the footprint >>>>>>> wizard? >>>>>>> Then it would be fantastic to have the repo contain scripts as you >>>>>>> say. >>>>>>> >>>>>>> Connectors are an obvious use for parametric scripts as it takes lots >>>>>>> of >>>>>>> space to store each of hundreds of variants. >>>>>>> >>>>>>> Oliver >>>>>>> >>>>>>> >>>>>>> On 25 Feb 2017 8:44 AM, "Cirilo Bernardo" <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> On Sat, Feb 25, 2017 at 1:12 AM, Simon Wells <[email protected]> >>>>>>> wrote: >>>>>>>> why should packages be a subfolder of modules, it seems that they >>>>>>>> don't really belong in there and should be directly in the >>>>>>>> share/kicad >>>>>>>> folder >>>>>>>> >>>>>>> >>>>>>> That would certainly be my preference. Since the root of the 3D >>>>>>> models >>>>>>> is >>>>>>> determined by KISYS3DMOD and hasn't had a hard-coded relation to the >>>>>>> *.lib files for quite a few years now, I would move it out of >>>>>>> 'modules' >>>>>>> and >>>>>>> into >>>>>>> a 'packages3d' directory. Looking at the structure on github, >>>>>>> 'packages3d' >>>>>>> is currently the only directory within 'modules' so the modules >>>>>>> directory >>>>>>> seems silly. >>>>>>> >>>>>>> >>>>>>>> On 25 February 2017 at 02:00, Adam Wolf >>>>>>>> <[email protected]> >>>>>>>> wrote: >>>>>>>>> Yeah, let me clarify--by "wouldn't be a problem" for OS X, I meant >>>>>>>>> "if >>>>>>>>> you did it without saying where it's going and when it's changing", >>>>>>>>> it >>>>>>>>> would break the OS X package, but the change would only take a >>>>>>>>> minute >>>>>>>>> or two, and would be quickly testable. >>>>>>>>> >>>>>>>>> On Fri, Feb 24, 2017 at 6:57 AM, Wayne Stambaugh >>>>>>>>> <[email protected]> >>>>>>>>> wrote: >>>>>>>>>> On 2/24/2017 3:45 AM, Oliver Walters wrote: >>>>>>>>>>> Hi everyone, >>>>>>>>>>> >>>>>>>>>>> Recently I raised this issue: >>>>>>>>>>> >>>>>>>>>>> https://lists.launchpad.net/kicad-developers/msg27922.html >>>>>>>>>>> >>>>>>>>>>> There were some good responses, thanks for the input. >>>>>>>>>>> >>>>>>>>>>> First task is going to be moving the 3D models, as this will be >>>>>>>>>>> significantly easier. >>>>>>>>>>> >>>>>>>>>>> e.g. something like GitHub.com/KiCad/packages3D >>>>>>>>>>> >>>>>>>>>>> To this end, I'd like some further information from those in the >>>>>>>>>>> know: >>>>>>>>>>> >>>>>>>>>>> A) is there any impediment to having the KISYS3DMOD envvar point >>>>>>>>>>> to >>>>>>>>>>> somewhere different? e.g. ./KiCad/share/packages3D/ >>>>>>>>>> >>>>>>>>>> I believe you mean share/kicad/modules/packages3d. Why would >>>>>>>>>> change >>>>>>>>>> the >>>>>>>>>> install path? Irregardless of what repo the 3D models are in, >>>>>>>>>> they >>>>>>>>>> should always get installed in this location. Where else would be >>>>>>>>>> appropriate to install them? Changing this path would most likely >>>>>>>>>> break >>>>>>>>>> everyone's 3D viewing experience. >>>>>>>>>> >>>>>>>>>>> B) To the package managers, how much effort to package 3D models >>>>>>>>>>> from >>>>>>>>>>> a >>>>>>>>>>> separate repo? >>>>>>>>>> >>>>>>>>>> I'll leave this to our package devs. >>>>>>>>>> >>>>>>>>>>> C) to the docs maintainers, would there be much to change if we >>>>>>>>>>> redirected the 3D repo? >>>>>>>>>>> D) Generally, what other considerations would be required? >>>>>>>>>>> >>>>>>>>>>> Essentially, if I made this change right now without telling >>>>>>>>>>> anyone, >>>>>>>>>>> what would I break? >>>>>>>>>> >>>>>>>>>> I'm sure all of the package builders. You would need to >>>>>>>>>> coordinate >>>>>>>>>> this >>>>>>>>>> change with the package devs. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> As a side note there have been some great recent contributions to >>>>>>>>>>> the >>>>>>>>>>> 3D >>>>>>>>>>> data, with a fair bit of momentum over at the forums. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Oliver >>>>>>> >>>>>>> Some thought is needed about how to handle the 3D model repository in >>>>>>> the >>>>>>> future. In the past we only had VRML which was pretty but next to >>>>>>> useless >>>>>>> for mechanical verification. Now we have IGES and STEP in all the >>>>>>> gloriously >>>>>>> ugly MCAD color schemes. Personally I only use IGES and STEP, but >>>>>>> some >>>>>>> people like to have a STEP model for mechanical verification and a >>>>>>> VRML >>>>>>> model for eyecandy. At the moment various scripts written to work >>>>>>> with >>>>>>> Maurice's StepUp tool are the only scheme I'm aware of which make it >>>>>>> easy >>>>>>> for people to have a STEP file while having improved material >>>>>>> appearances >>>>>>> applied to the surfaces in a corresponding VRML file. I suspect it is >>>>>>> inevitable >>>>>>> that we start to have a diverse collection of 3D model sources: >>>>>>> >>>>>>> a. old VRML models with no corresponding MCAD model >>>>>>> b. IGES/STEP models from manufacturers with no aesthetic coloring >>>>>>> c. script-based parametric generators which produce STEP models and >>>>>>> corresponding VRML models with aesthetic material appearances >>>>>>> >>>>>>> For (c) it really makes no sense to store the models themselves >>>>>>> because >>>>>>> these can really waste storage space. My preference is for the >>>>>>> scripts >>>>>>> to >>>>>>> be made available for various tools (StepUp being the only one so >>>>>>> far) >>>>>>> and for the end user to install the tools. >>>>>>> >>>>>>> - Cirilo >>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>>>>> Post to : [email protected] >>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>>>> Post to : [email protected] >>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>>> Post to : [email protected] >>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>> Post to : [email protected] >>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>> Post to : [email protected] >>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>> >>>>>>> >>>>>> >>>>>> >>> >>> >> >> > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
