kicad-developers team mailing list archive

[José Ignacio <jose.cyborg@xxxxxxxxx>]

I feel it would be important to have the freest possible license for
generated models and footprints as to not interfere with uses of the
library, in the interest of unifying library development and avoiding
license splits. (aside from the fact that copyright on some of those things
is a bit tenuous).

On Sun, Feb 26, 2017 at 11:21 AM, Wayne Stambaugh <stambaughw@xxxxxxxxx>
wrote:

> 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
> >
>
>
> _______________________________________________
> 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
>