Very tough to design in pure openscad
link to download:
https://github.com/sprabhakar2006/openSCAD/blob/main/bottle%20with%20cut%20design.scad

[image: Screenshot 2023-09-19 at 5.56.51 AM.png]

[image: Screenshot 2023-09-19 at 6.00.32 AM.png]

i have got somebody asking a question regarding  the Constructive
library here: https://github.com/solidboredom/constructive/issues/5

if it can be dual licensed under OHL-S (v2). It is now under GPL2 (just
because i have known it and its principles for very many years)

Now i wonder, what would it be a suitable License for the Constructive Lib?

I feel the lib  is much more an extension to the Openscad Language
itself, like list comprehentions to python, or LINQ to c#, rather than a
library in usual sense. It is just all written in openscad, so it can be
imported as a library. and technically it is one.The Lib does provide
few ready-made Parts, like some metric screws, but its focus is not
that, but rather on enabling the user to express more with less code and
make it flexible enough to create reasonably complex designs.

So how to license it, so it will stay compatible with Openscad's
licensing and enable most people to use it?

I would like to encourage people to use it, because i personally think
it makes so much sense. to not hamper peoples use of it in their
hardware by the license.

The only thing i might not like (i am not even sure), if somebody
derives code from it, closing it. But actually i do not mean the Parts
themselves or their designs. they IMHO do not have to be open.

what are you opinions on this?

is OHL-S (v2) a good solution, does it negate GPL principles in our
case? is it compatible with Openscads license?

Your Opinions are very appreciated.

pproj

Look, for example, at the widely used threads_2.5.scad in
https://www.printables.com/model/379145-nuts-and-bolts-v195-openscad-library/files

The statement

metric_thread(length=4);

evaluates to the following in the 2021.1 release, but

[image: Screenshot 2023-09-19 at 9.55.57 PM.png]

evaluates to this in the dev builds.

[image: Screenshot 2023-09-19 at 9.55.25 PM.png]

The culprit is in module metric_thread_turns

which has

intersection () {

  // Start one below z = 0.  Gives an extra turn at each end.

  for (i=[-1*n_starts : n_turns+1]) {

     translate ([0, 0, i*pitch]) {

        metric_thread_turn (diameter, pitch, internal, n_starts,

                            thread_size, groove, square, rectangle,

angle,

                            taper, i*pitch);

     }

  }

  // Cut to length.

  translate ([0, 0, length/2]) {

     cube ([diameter*3, diameter*3, length], center=true);

  }

}

in the release build the for() has an implicit union.

In the dev build, to fix this, we have to add an explicit union:

intersection () {

  *union*(){ // <===

     // Start one below z = 0.  Gives an extra turn at each end.

     for (i=[-1*n_starts : n_turns+1]) {

        translate ([0, 0, i*pitch]) {

           metric_thread_turn (diameter, pitch, internal, n_starts,

                               thread_size, groove, square, rectangle,

angle,

                               taper, i*pitch);

        }

     }

  }

I think, in general, that this is a good fix, but it silently breaks a lot
of old code.

Is there any way to detect this and add a warning on the console, or some
other way for a naive programmer to quickly find problems like this?