kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

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
> <oliver.henry.walters@xxxxxxxxx> 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" <cirilo.bernardo@xxxxxxxxx>
>> 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
>> <oliver.henry.walters@xxxxxxxxx> 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" <cirilo.bernardo@xxxxxxxxx> wrote:
>>>
>>> On Sat, Feb 25, 2017 at 3:53 PM, Oliver Walters
>>> <oliver.henry.walters@xxxxxxxxx> 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" <swel024@xxxxxxxxx> 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
>>>>> <oliver.henry.walters@xxxxxxxxx> 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" <cirilo.bernardo@xxxxxxxxx>
>>>>>> 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
>>>>>> <oliver.henry.walters@xxxxxxxxx> 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" <cirilo.bernardo@xxxxxxxxx>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On Sat, Feb 25, 2017 at 1:12 AM, Simon Wells <swel024@xxxxxxxxx>
>>>>>>> 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
>>>>>>>> <adamwolf@xxxxxxxxxxxxxxxxxxxx>
>>>>>>>> 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
>>>>>>>>> <stambaughw@xxxxxxxxx>
>>>>>>>>> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>
>>
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>