Anonymous usage statistics

[TheFuzzyGiggler]

I’m definitely no expert in GPL litigation, but that brings up some conundrums and I have the same assumptions as Sineos.

The GCode Macro function can only use the modules and functions built into Klipper which is covered by GPL.

They might use it in a fancy way, but they’re still just using Klipper. If they add modules, that’s covered under the GPL license.

In fact, I think the GPL license would consider this an “Aggregate” program and covered under the same GPL license because it’s tied to the Klipper executable.

Edit: Not aggregate based on the wording, it would be considered Klipper itself. But again, I’m not a lawyer but I feel like someone would have a hell of a time explaining how their macro that is in Klipper, using Klipper, bundled with Klipper isn’t covered by the Klipper license.

What is the difference between an “aggregate” and other kinds of “modified versions”? (#MereAggregation)

An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are nonfree or GPL-incompatible. The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program’s individual license would grant them.

Where’s the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

[Sineos]

Well, apart from the legal discussion (where I believe, we would be covered), the point really is:

• Should all the config items be collected and permanently stored?
• Does it make sense to have 100,000 DB entries on macros called [gcode_macro PAUSE]?
• Would it make more sense to maybe just store the titles to see, which kind of macros are most commonly used?
• Collecting data for the sake of collecting data, but in the end doing nothing with them, is neither efficient nor economical

[olhev]

I guess someone will be tasked with solving it by debugging it, or they’ll find a solution, maybe by hiring someone with more skills bound by secrecy.

It doesn’t matter, are you the one to decide that they can only solve it by publishing what they don’t want to so the macros MUST be shared with the klipper developers?

Seems quite an arrogant position.

[olhev]

Macros don’t seem to me part of the Klipper code, it’s stuff which could be theoretically thought as code which could go in gcode as well.
Maybe they don’t count as source code but it’s also true that Klipper seems to compile them into the executable at runtime, since they require a restart of klipper to be usable.

If not part of the source code they don’t follow GPL, like an image or a macro in GIMP doesn’t need to be GPL. If they are code intrinsically linked to klipper, then they might need to.

Anyway, I would weigh really well the advantages of sending out macros Vs potential issues.
And for opt-out, it should be offered for macros as separate option.

In my opinion.

[mykepredko]

Reading this, you come across as new but when I look you up you’ve apparently been here a while.

Which is surprising, because you act like you’ve never seen a request where the poster has edited the klippy.log and the response is always that help can’t be given without the complete and unedited file.

That is simply where I’m coming from.

Personally, I don’t care what somebody does with their printers I’m simply pointing out that if they don’t include all the information when requesting help, they won’t get any here.

[olhev]

I also think the added value of macros is negligible for practical purposes.
In fact, not even the names would bring much gain…

On the other hand, configurations are much more easily parsable into statistical summaries which might help to steer the development or to evaluate proposed features.

[olhev]

I don’t know anyone having secret stuff in their macros but I’m sure whoever does wouldn’t come here posting the klippy.log.

It’s like saying that no one would ever think about going to the beach naked because you only visited no-nudity beaches.

Basically you can’t use an environment with certain rules to exclude the existence of other environments which don’t interact with the one you use as basis.

[TheFuzzyGiggler]

At best I think macros would be considered a “plug-in” for Klipper. Which is still covered under GPL in this cause because they run under the same executable. Basically you can’t run a Klipper gcode macro without running Klipper. So they’re intimately tied together.

It’s covered under the second paragraph on the first question. Since gcode macros are dynamically linked and make function calls within Klipper.

When is a program and its plug-ins considered a single combined program? (#GPLPlugins)

It depends on how the main program invokes its plug-ins. If the main program uses fork and exec to invoke plug-ins, and they establish intimate communication by sharing complex data structures, or shipping complex data structures back and forth, that can make them one single combined program. A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program.

If the main program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single combined program, which must be treated as an extension of both the main program and the plug-ins. If the main program dynamically links plug-ins, but the communication between them is limited to invoking the ‘main’ function of the plug-in with some options and waiting for it to return, that is a borderline case.

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

If I write a plug-in to use with a GPL-covered program, what requirements does that impose on the licenses I can use for distributing my plug-in? (#GPLAndPlugins)

Please see this question for determining when plug-ins and a main program are considered a single combined program and when they are considered separate works.

If the main program and the plugins are a single combined program then this means you must license the plug-in under the GPL or a GPL-compatible free software license and distribute it with source code in a GPL-compliant way. A main program that is separate from its plug-ins makes no requirements for the plug-ins.