Live data from Hacker News

Plasticity Is CAD for Artists

github.com

101–109 of 109 posts

Re: Plasticity Is CAD for Artists

#101
post #79

Earlier quoted context omitted.

THIS!! I've also been using CAD professionally for nearly two decades (RhinoCAD), and was intrigued by the title. When I saw it was just a GitHub code page, without even much for documentation, etc. My response was basically "nevermind", although I did come to check the comments - the video definitely highlights capabilities in a way I would never have guessed form the GH link. In short, some basics that I learned wh…

It hasn't even launched. It just got submitted to HN by some rando, not the dev.

I knew it hadn't yet launched. thx for the update on the poster.

Still, the knowledge was hard-won, and I hope it helps someone else on the forum. I've had people randomly provide me with a few of their hard-won gems over the years, which when I applied it made substantial positive differences in my career.

It seemed relevant to the topic, even if not in the strict sense of advising directly the developer in this specific conversation. (Also, it'd not unlikely that the Dev would have the convo brought to his/her attention, so it may end up there anyway).

Re: Plasticity Is CAD for Artists

#102
post #96

Earlier quoted context omitted.

But why would a GPL app need to force GPL on a plugin? That seems to me like a perfectly reasonable boundary between the two applications. If I wanted to leverage OBS for example and introduce my own plugin that made use of a closed-source library or tool I had the license for, I should be able to create it. My third-party plugin doesn't impede the distribution and usage of OBS in any way, only provides a separate fe…

As someone who spends most of his days on a GPL app which loads plug-ins, I do not want my work to serve the interest of proprietary software vendors more than strictly necessary, simple as that. I spent the effort of writing the app, defining its plug-in APIs, etc; if others want to benefit from this effort they should also spend the effort of writing GPL plug-ins. The end result is that no end user will ever be stu…

Because I'm not beholden to your ideals. GPL is tantamount to a parasite, infecting everything it touches, regardless of the wishes of those who'd make use of the GPL'd software.

I was a contributor to FOSS until I had to make a choice to step back from excessive keyboard use due to RSI. I love and embrace open source software and the ideals behind it, but I believe everyone should be given their own freedoms.

The plugin boundary should be exactly that, a boundary between the primary app and any created plugins. Why do you feel entitled to force a license decision on a third party's work? Yeah, my work might not function without your code, but your code is your code and my plugin is mine. If I choose to write a utility that enhances your code in ways I want, is that not the benefit and flexibility that FOSS clamors about? Hell, what if someone else adopts a similar API and I choose to take my plugin that direction? That's my choice to make, but forcing GPL on my code may now be hampering my freedoms.

I hear the argument of "if only software X was open source, then I could fix this bug here or add this feature there". I'm right there with you on code that is in the mainline and lives inside the source, but if I'm writing a plugin, that's my work and I own that, not you.

If I choose to make use of a proprietary library because it makes sense to me, like for example CAD solvers where the FOSS alternatives aren't there yet, that's my decision for my plugin. All your GPL license does is infect my work.

That's why I don't use GPL, and why I agree with others that the end result of many GPL licenses is to simply reduce the overall amount of GPL code in the world, as people avoid it out of concern of risk.

Re: Plasticity Is CAD for Artists

#103
post #101

Earlier quoted context omitted.

It hasn't even launched. It just got submitted to HN by some rando, not the dev.

I knew it hadn't yet launched. thx for the update on the poster. Still, the knowledge was hard-won, and I hope it helps someone else on the forum. I've had people randomly provide me with a few of their hard-won gems over the years, which when I applied it made substantial positive differences in my career. It seemed relevant to the topic, even if not in the strict sense of advising directly the developer in this spe…

> so it may end up there anyway

Yeah, like this, the GP if your very own comment: https://news.ycombinator.com/item?id=30698861

Re: Plasticity Is CAD for Artists

#104
post #102

Earlier quoted context omitted.

As someone who spends most of his days on a GPL app which loads plug-ins, I do not want my work to serve the interest of proprietary software vendors more than strictly necessary, simple as that. I spent the effort of writing the app, defining its plug-in APIs, etc; if others want to benefit from this effort they should also spend the effort of writing GPL plug-ins. The end result is that no end user will ever be stu…

Because I'm not beholden to your ideals. GPL is tantamount to a parasite, infecting everything it touches, regardless of the wishes of those who'd make use of the GPL'd software. I was a contributor to FOSS until I had to make a choice to step back from excessive keyboard use due to RSI. I love and embrace open source software and the ideals behind it, but I believe everyone should be given their own freedoms. The pl…

> I believe everyone should be given their own freedoms.

Absolute freedom does not exist (or even make sense).

> The plugin boundary should be exactly that, a boundary between the primary app and any created plugins. Why do you feel entitled to force a license decision on a third party's work?

That's the expectation I set when I develop the host software. If I was fine with third party proprietary plug-ins I could set my plug-in headers as MIT or something. Just like if I only wanted my software be used by people who have no revenue or live in $COUNTRY I would put that as a license instead of the GPL.

> Yeah, my work might not function without your code, but your code is your code and my plugin is mine.

this is super super entitled. You're fine with leveraging GPL work which is release for free for your own benefit, but do not want to reciprocate. As I posted elsewhere: https://en.wikipedia.org/wiki/Golden_Rule ; this is the most basic expectation one can have.

> but your code is your code and my plugin is mine.

but the GPL code is and will forever be freely available ; anything that goes against increasing the pool of freely available thing is a no-go. The end goal of all that would be to change laws so that ownership of ideas, patents, etc..., is itself ended ; ultimately, licenses and copyright shouldn't even need to exist.

> If I choose to make use of a proprietary library because it makes sense to me, like for example CAD solvers where the FOSS alternatives aren't there yet, that's my decision for my plugin. All your GPL license does is infect my work.

Again you seem to forget that your plug-in depends on an existing host software and seem to want to use the work done there without giving anything in return. If there was some kind of public standard for CAD solvers so that the GPL part of your plug-in could be also used with free solvers, that would be a non-issue - ship your plug-in, and end-users can install a free solver or a proprietary one separately if they are fine with proprietary code.

Re: Plasticity Is CAD for Artists

#105

Earlier quoted context omitted.

I think so. I originally said there were a lot of holes in their argument, but I think they didn't actually make an argument in the first place, they just made a claim with no evidence behind it.

The GPL does not care about stuff such as libraries, executable, etc. The only relevant concern is whether your IPC-splitted thing is part of the program, or is a public API expected to be used by many unrelated other programs. Quoting the GPL: > The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modi…

There are a lot of things being conflated here.

First is a plugin that would be shared library loaded into the same virtual memory space as a running program.

The second is GPLed header files that define function signatures and data structures.

The third scenario would be passing already defined data formats like JSON or something serialized through the file system, shared memory, or the local network. In this situation, there would be separate processes, separate memory spaces and no interface definitions would need to be included into the non GPLed program. This situation can't violated the GPL because it would imply that almost any communication with a GPLed program would violate the GPL.

Re: Plasticity Is CAD for Artists

#106

Earlier quoted context omitted.

The GPL does not care about stuff such as libraries, executable, etc. The only relevant concern is whether your IPC-splitted thing is part of the program, or is a public API expected to be used by many unrelated other programs. Quoting the GPL: > The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modi…

There are a lot of things being conflated here. First is a plugin that would be shared library loaded into the same virtual memory space as a running program. The second is GPLed header files that define function signatures and data structures. The third scenario would be passing already defined data formats like JSON or something serialized through the file system, shared memory, or the local network. In this situat…

> This situation can't violated the GPL because it would imply that almost any communication with a GPLed program would violate the GPL.

any intimate communication would indeed. Any communication that goes through a standard (e.g. ISO-defined or industry standard, so not something specific to your company) would not.

Quoting the FSF:

> Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.

You can obviously extend "communicating complex data structures" to RPC through JSON & websockets for instance as it's this "exchange of complex data structures" which is the defining matter in what constitutes a single program from the point of view of the GPL.

Re: Plasticity Is CAD for Artists

#107

Earlier quoted context omitted.

There are a lot of things being conflated here. First is a plugin that would be shared library loaded into the same virtual memory space as a running program. The second is GPLed header files that define function signatures and data structures. The third scenario would be passing already defined data formats like JSON or something serialized through the file system, shared memory, or the local network. In this situat…

> This situation can't violated the GPL because it would imply that almost any communication with a GPLed program would violate the GPL. any intimate communication would indeed. Any communication that goes through a standard (e.g. ISO-defined or industry standard, so not something specific to your company) would not. Quoting the FSF: > Using shared memory to communicate with complex data structures is pretty much equ…

any intimate communication would indeed.

I gave specific examples and you keep using an abstract label.

> Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking.

These are two separate things unless they are talking about shared memory meaning sharing the same memory space as another process, which is what dynamic linking does.

Communicating through complex data structures can describe files too. If you save a file from one GPLed program and open it in a non GPLed program, that is interprocess communication. If both programs are using mmap on the files instead of writes, does that change things? If files are being sent over local loop back does that change things?

Are there any examples of any of these ideas being tested? I've never heard of anyone except for you asserting that two processes communicating without including GPLed source code was somehow a GPL violation.

Re: Plasticity Is CAD for Artists

#108

Earlier quoted context omitted.

> This situation can't violated the GPL because it would imply that almost any communication with a GPLed program would violate the GPL. any intimate communication would indeed. Any communication that goes through a standard (e.g. ISO-defined or industry standard, so not something specific to your company) would not. Quoting the FSF: > Using shared memory to communicate with complex data structures is pretty much equ…

any intimate communication would indeed. I gave specific examples and you keep using an abstract label. > Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking. These are two separate things unless they are talking about shared memory meaning sharing the same memory space as another process, which is what dynamic linking does. Communicating through complex data s…

> I gave specific examples and you keep using an abstract label.

I am quoting the license text.

> Communicating through complex data structures can describe files too. If you save a file from one GPLed program and open it in a non GPLed program, that is interprocess communication. If both programs are using mmap on the files instead of writes, does that change things? If files are being sent over local loop back does that change things?

I don't thinkg it would at all - it would still breach the license if e.g. you are dumping raw struct contents in your files that are only meaningful for the proprietary side of things.

See https://opensource.stackexchange.com/questions/8505/gpl-appl...

Re: Plasticity Is CAD for Artists

#109

Earlier quoted context omitted.

any intimate communication would indeed. I gave specific examples and you keep using an abstract label. > Using shared memory to communicate with complex data structures is pretty much equivalent to dynamic linking. These are two separate things unless they are talking about shared memory meaning sharing the same memory space as another process, which is what dynamic linking does. Communicating through complex data s…

> I gave specific examples and you keep using an abstract label. I am quoting the license text. > Communicating through complex data structures can describe files too. If you save a file from one GPLed program and open it in a non GPLed program, that is interprocess communication. If both programs are using mmap on the files instead of writes, does that change things? If files are being sent over local loop back does…

I am quoting the license text.

The part you are quoting is still an abstract label. You can't take specific common scenarios and say 'intimate communication is banned' when 'intimate communication' is not defined well.

you are dumping raw struct contents in your files that are only meaningful for the proprietary side of things.

What does that even mean? You could work with the bmp file format internally as a frame buffer in a program because it is uncompressed. Does that mean if you write a bmp file out of gimp and open it in photoshop you are violating the GPL? If so, why has that never been brought up or asserted by any person or company ever?

The things you are saying don't seem to line up with what anyone else thinks. When has anyone else tried to claim that you can't send files from one GPL program to another non GPL program?

I think you should consider whether you are trying to claiming something is true because you want it to be true, not because it makes sense.

Post reply on HN