replace pipeworks w/ techpack #4514

Closed
opened 2023-05-17 02:58:55 +00:00 by flux · 37 comments
Member

there is an admin issue about this, but that's not public.

removing pipeworks will not result in unknown nodes. you will be able to trade in your old machines for the materials you used to build them.

however, your machines will stop working.

this is incredibly controversial, but despite the loss of player time, i think it would ultimately result in a more maintainable server.

there is [an admin issue](https://gitea.your-land.de/your-land/administration/issues/112#issue-2340) about this, but that's not public. removing pipeworks will *not* result in unknown nodes. you will be able to trade in your old machines for the materials you used to build them. however, your machines will stop working. this is incredibly controversial, but despite the loss of player time, i think it would ultimately result in a more maintainable server.

I worked with tubelib a while on another server.
For experimental use this was okay, but for production purpose it's not that funny that every now and than the parts get broken and have to be fixed.
Another probelm was: everytime I tried to build an automatic door, the server crashed.
I think the gravel sieve should not be used due to balancing.
Also some other parts (Tubelib Quarry) might be a balancing problem.
But the tubes are fine.

I worked with tubelib a while on another server. For experimental use this was okay, but for production purpose it's not that funny that every now and than the parts get broken and have to be fixed. Another probelm was: everytime I tried to build an automatic door, the server crashed. I think the [gravel sieve](https://github.com/joe7575/techpack/wiki/gravelsieve#Automatic-Gravel-Sieve) should not be used due to balancing. Also some other parts (Tubelib Quarry) might be a balancing problem. But the tubes are fine.

part breaking can be reduced or eliminated in tubelib config. Not sure if the machinery (biofuel-based quarry, harvester, ...) would fit style.

Note that removing pipeworks would cause unknown nodes, but replacing it with some pipeworks stub mod that define node look and deconstruction recipes will be ok.

Also, could both be active during transition period? Those mods should not be node heavy, so likely ok with node limit.

part breaking can be reduced or eliminated in tubelib config. Not sure if the machinery (biofuel-based quarry, harvester, ...) would fit style. Note that removing pipeworks would cause unknown nodes, but replacing it with some pipeworks stub mod that define node look and deconstruction recipes will be ok. Also, could both be active during transition period? Those mods should not be node heavy, so likely ok with node limit.
Author
Member

Would like to see this on a spin-up server

my fluxtest server (on the public server list, or fluxtest.sixths.net:30000) has a large proportion of the your-land mods, and is meant for testing new mechanics. tubelib/techpack is installed there, or at least the parts of it i think are appropriate for your-land.

Teleport tube gets heavy use when collecting resources "in the field"

techpack has teleporters. these are paired, point-to-point; there's no possibility of multiple sources and multiple destinations w/ the same "tag". there's also apparently no way to prevent connections based on player name; perhaps that's something that could be added. but there's no risk of someone else connecting to your teleporter if it's paired w/ another.

Proposed action to add metatool for Tube Tool, Lua Tool, Container Tool, Magic Pen; is there tubelib compatibility?

there's nothing like the tube tool (which is used for copying e.g. sorting tube configuration?). the other tools would work like they did before.

every now and than the parts get broken and have to be fixed.

this behavior is configurable and can be disabled.

removing pipeworks would cause unknown nodes, but replacing it with some pipeworks stub mod that define node look and deconstruction recipes will be ok.

that is 100% the plan, and we plan to do it in a way that we can reverse the process if necessary.

could both be active during transition period

plausible

should not be node heavy, so likely ok with node limit.

pipeworks nodes will never be fully removed, but tubelib doesn't nearly as many as pipeworks does (mostly from pipe variants).

> Would like to see this on a spin-up server my fluxtest server (on the public server list, or fluxtest.sixths.net:30000) has a large proportion of the your-land mods, and is meant for testing new mechanics. tubelib/techpack is installed there, or at least the parts of it i think are appropriate for your-land. > Teleport tube gets heavy use when collecting resources "in the field" techpack has [teleporters](https://github.com/joe7575/techpack/wiki/addons3#tubelib-teleporter). these are paired, point-to-point; there's no possibility of multiple sources and multiple destinations w/ the same "tag". there's also apparently no way to prevent connections based on player name; perhaps that's something that could be added. but there's no risk of someone else connecting to your teleporter if it's paired w/ another. > Proposed action to add metatool for Tube Tool, Lua Tool, Container Tool, Magic Pen; is there tubelib compatibility? there's nothing like the tube tool (which is used for copying e.g. sorting tube configuration?). the other tools would work like they did before. > every now and than the parts get broken and have to be fixed. this behavior is configurable and can be disabled. > removing pipeworks would cause unknown nodes, but replacing it with some pipeworks stub mod that define node look and deconstruction recipes will be ok. that is 100% the plan, and we plan to do it in a way that we can reverse the process if necessary. > could both be active during transition period plausible > should not be node heavy, so likely ok with node limit. pipeworks nodes will never be fully removed, but tubelib doesn't nearly as many as pipeworks does (mostly from pipe variants).

Here are some issues that I see with this proposal.

  1. Techpack nodes seem to be entirely incompatible with digilines. They instead use their own SmartLine protocol. Similarly, LuaControllers are useless for controlling SmartLine nodes. As such, the scope of material refunding/conversion really should be broader. Pipeworks being removed also devalues all the gold spent on digilines stuff for pipeworks-based machines.

  2. Techpack's teleporter node has substantial deficiencies when compared to pipeworks' teleport tubes. Most glaring are the inability of techpack teleporters supporting multiple producer / single consumer teleport layouts, and the lack of a smartline command API for techpack teleporters. The combination of these two missing features renders the designs of most of my machines impossible to recreate with Techpack. As such, I don't want to see a Techpack switch-over without substantial improvement to its teleporter feature set.

  3. The pipeworks water pipe connections for wine mod's barrels have no analog in Techpack.

  4. The AGPL licensing of Techpack seems like it may make Techpack fundamentally incompatible with YL. Presumably YL is implemented as a monolithic mod, with all other mods functionally being dependent mods of the YL "mother" mod. The impact of this may be that the AGPL's copyleft provisions apply to the entire YL codebase. This ought to be considered carefully, as it means that adopting TechPack without releasing the rest of YL under the AGPL may lead to license violations (meaning YL could be liable for copyright infringement).

Here are some issues that I see with this proposal. 1. Techpack nodes seem to be entirely incompatible with digilines. They instead use their own SmartLine protocol. Similarly, LuaControllers are useless for controlling SmartLine nodes. As such, the scope of material refunding/conversion really should be broader. Pipeworks being removed also devalues all the gold spent on digilines stuff for pipeworks-based machines. 2. Techpack's teleporter node has substantial deficiencies when compared to pipeworks' teleport tubes. Most glaring are the inability of techpack teleporters supporting multiple producer / single consumer teleport layouts, and the lack of a smartline command API for techpack teleporters. The combination of these two missing features renders the designs of most of my machines impossible to recreate with Techpack. As such, I don't want to see a Techpack switch-over without substantial improvement to its teleporter feature set. 3. The pipeworks water pipe connections for wine mod's barrels have no analog in Techpack. 4. The AGPL licensing of Techpack seems like it may make Techpack fundamentally incompatible with YL. Presumably YL is implemented as a monolithic mod, with all other mods functionally being dependent mods of the YL "mother" mod. The impact of this may be that the AGPL's copyleft provisions apply to the entire YL codebase. This ought to be considered carefully, as it means that adopting TechPack without releasing the rest of YL under the AGPL may lead to license violations (meaning YL could be liable for copyright infringement).
Author
Member
  1. Techpack nodes seem to be entirely incompatible with digilines. They instead use their own SmartLine protocol. Similarly, LuaControllers are useless for controlling SmartLine nodes. As such, the scope of material refunding/conversion really should be broader. Pipeworks being removed also devalues all the gold spent on digilines stuff for pipeworks-based machines.

smartline is absolutely terrible and is not part of the subset of techpack that i suggest installing. i'll make a full list of that at the bottom of this comment.

luacontrollers can currently interact w/ techpack via techpacks' mesecons converter. it's basic and clunky, but i've certainly used such a setup.

i am very much interested in providing first-class digilines support to tubelib/techpack, and if it looks like your-land will actually go that direction, i'll write that code and create a PR. i haven't contributed much to tubelib recently, but i've got a decent relationship w/ Joe7575.

  1. Techpack's teleporter node has substantial deficiencies when compared to pipeworks' teleport tubes. inability of techpack teleporters supporting multiple producer / single consumer teleport layouts, and the lack of a smartline command API for techpack teleporters. The combination of these two missing features renders the designs of most of my machines impossible to recreate with Techpack. As such, I don't want to see a Techpack switch-over without substantial improvement to its teleporter feature set.

you're describing a feature of techpack, not a bug. it doesn't support anything other than 1:1 connections, outside of distributors and the pushing chest. the mod is not in 1:1 feature parity w/ pipeworks, because it has different design goals. it requires a very different design discipline to make use of it, but it's easier to learn the basics and is better for server performance. while you may not be able to exactly replicate the machines you're used to, i've made massive machines out of tubelib/techpack that would never be remotely possible w/ pipeworks.

  1. The pipeworks water pipe connections for wine mod's barrels have no analog in Techpack.

i didn't even realize that wine had a pipeworks hookup, it'd be pretty easy to create such a device w/ techpack.

  1. The AGPL licensing of Techpack seems like it may make Techpack fundamentally incompatible with YL. Presumably YL is implemented as a monolithic mod, with all other mods functionally being dependent mods of the YL "mother" mod. The impact of this may be that the AGPL's copyleft provisions apply to the entire YL codebase. This ought to be considered carefully, as it means that adopting TechPack without releasing the rest of YL under the AGPL may lead to license violations (meaning YL could be liable for copyright infringement).

AGPL doesn't work that way, that's a common bit of pernicious propaganda. however, Alias does want to release a "full YL server mod list" that doesn't come w/ the AGPL's restrictions even in part, so the point is moot. i didn't it'd gone AGPL, it wasn't when i was working with it.

> 1. Techpack nodes seem to be entirely incompatible with digilines. They instead use their own SmartLine protocol. Similarly, LuaControllers are useless for controlling SmartLine nodes. As such, the scope of material refunding/conversion really should be broader. Pipeworks being removed also devalues all the gold spent on digilines stuff for pipeworks-based machines. smartline is *absolutely terrible* and is not part of the subset of techpack that i suggest installing. i'll make a full list of that at the bottom of this comment. luacontrollers can currently interact w/ techpack via techpacks' mesecons converter. it's basic and clunky, but i've certainly used such a setup. i am very much interested in providing first-class digilines support to tubelib/techpack, and if it looks like your-land will actually go that direction, i'll write that code and create a PR. i haven't contributed much to tubelib recently, but i've got a decent relationship w/ Joe7575. > 2. Techpack's teleporter node has substantial deficiencies when compared to pipeworks' teleport tubes. inability of techpack teleporters supporting multiple producer / single consumer teleport layouts, and the lack of a smartline command API for techpack teleporters. The combination of these two missing features renders the designs of most of my machines impossible to recreate with Techpack. As such, I don't want to see a Techpack switch-over without substantial improvement to its teleporter feature set. you're describing a feature of techpack, not a bug. it doesn't support anything other than 1:1 connections, outside of distributors and the pushing chest. the mod is not in 1:1 feature parity w/ pipeworks, because it has different design goals. it requires a very different design discipline to make use of it, but it's easier to learn the basics and is better for server performance. while you may not be able to exactly replicate the machines you're used to, i've made massive machines out of tubelib/techpack that would never be remotely possible w/ pipeworks. > 3. The pipeworks water pipe connections for wine mod's barrels have no analog in Techpack. i didn't even realize that wine had a pipeworks hookup, it'd be pretty easy to create such a device w/ techpack. > 4. The AGPL licensing of Techpack seems like it may make Techpack fundamentally incompatible with YL. Presumably YL is implemented as a monolithic mod, with all other mods functionally being dependent mods of the YL "mother" mod. The impact of this may be that the AGPL's copyleft provisions apply to the entire YL codebase. This ought to be considered carefully, as it means that adopting TechPack without releasing the rest of YL under the AGPL may lead to license violations (meaning YL could be liable for copyright infringement). AGPL doesn't work that way, that's a common bit of pernicious propaganda. however, Alias *does* want to release a "full YL server mod list" that doesn't come w/ the AGPL's restrictions even in part, so the point is moot. i didn't it'd gone AGPL, it wasn't when i was working with it.
Author
Member

part of my unfinished 5th gen techpack factory on blocky survival: image

part of my unfinished 5th gen techpack factory on blocky survival: ![image](/attachments/4bfdfc9f-59b3-47d9-ad37-af2fc065d915)
1.6 MiB
Author
Member

part of an auto-sorting inventory system image

part of an auto-sorting inventory system ![image](/attachments/ee9b7b88-fd4c-48cb-8926-903d39c92e63)
651 KiB

you're describing a feature of techpack, not a bug. it doesn't support anything other than 1:1 connections, outside of distributors and the pushing chest. the mod is not in 1:1 feature parity w/ pipeworks, because it has different design goals. it requires a very different design discipline to make use of it, but it's easier to learn the basics and is better for server performance. while you may not be able to exactly replicate the machines you're used to, i've made massive machines out of tubelib/techpack that would never be remotely possible w/ pipeworks.

One pattern that I use involves loading items from centralized storage into different machines. I achieve this by altering teleport tube channels on the fly (via digilines). This cannot be done with techpack currently.

Frankly, without digiline support, I don't think this is a good fit.

> you're describing a feature of techpack, not a bug. it doesn't support anything other than 1:1 connections, outside of distributors and the pushing chest. the mod is not in 1:1 feature parity w/ pipeworks, because it has different design goals. it requires a very different design discipline to make use of it, but it's easier to learn the basics and is better for server performance. while you may not be able to exactly replicate the machines you're used to, i've made massive machines out of tubelib/techpack that would never be remotely possible w/ pipeworks. One pattern that I use involves loading items from centralized storage into different machines. I achieve this by altering teleport tube channels on the fly (via digilines). This cannot be done with techpack currently. Frankly, without digiline support, I don't think this is a good fit.
  1. The AGPL licensing of Techpack seems like it may make Techpack fundamentally incompatible with YL. Presumably YL is implemented as a monolithic mod, with all other mods functionally being dependent mods of the YL "mother" mod. The impact of this may be that the AGPL's copyleft provisions apply to the entire YL codebase. This ought to be considered carefully, as it means that adopting TechPack without releasing the rest of YL under the AGPL may lead to license violations (meaning YL could be liable for copyright infringement).

Using single AGPL mod on server would mean it would be necessary to give access to the source of ALL of the mods and also to the server (I assume the server code is also somewhat modified). AGPL is equivalent to GPL (if you modify library, you need to release everything) and not LGPL (if you modify library/mod, you need to release only the library) in this regard.

There is older techpack version that is not AGPL. Likely missing some features and possibly having some extra bugs :)

> 4. The AGPL licensing of Techpack seems like it may make Techpack fundamentally incompatible with YL. Presumably YL is implemented as a monolithic mod, with all other mods functionally being dependent mods of the YL "mother" mod. The impact of this may be that the AGPL's copyleft provisions apply to the entire YL codebase. This ought to be considered carefully, as it means that adopting TechPack without releasing the rest of YL under the AGPL may lead to license violations (meaning YL could be liable for copyright infringement). Using single AGPL mod on server would mean it would be necessary to give access to the source of ALL of the mods and also to the server (I assume the server code is also somewhat modified). AGPL is equivalent to GPL (if you modify library, you need to release everything) and not LGPL (if you modify library/mod, you need to release only the library) in this regard. There is older techpack version that is not AGPL. Likely missing some features and possibly having some extra bugs :)

As far as I understand AGPL, I need to provide a link to where a mod comes from or to the source when I modified it. AGPL is no virus that contaminates the other mods.

Imagine I had a "commercial" mod that is YL exclusive and its license says I must not publish it because the license covers only me using it, but not release source. How would AGPL have a say in what other mods do?

We're already using AGPL mods like canned food: https://gitea.your-land.de/your-land/canned_food which we did publish due to AGPL.

Eventually when we publish all our mods, we'll hopefully have a /license command that details for every mod which license they fall under and where the YL branch is and where upstream comes from.

As far as I understand AGPL, I need to provide a link to where a mod comes from or to the source when I modified it. AGPL is no virus that contaminates the other mods. Imagine I had a "commercial" mod that is YL exclusive and its license says I must not publish it because the license covers only me using it, but not release source. How would AGPL have a say in what other mods do? We're already using AGPL mods like canned food: https://gitea.your-land.de/your-land/canned_food which we did publish due to AGPL. Eventually when we publish all our mods, we'll hopefully have a `/license` command that details for every mod which license they fall under and where the YL branch is and where upstream comes from.

IANAL, but AGPL is "viral" similarly to GPL, except that user is not the one that has access to the binaries, but in case of AGPL user that connects via network (in this case a registered player on YL). AGPL changes only what "conveying" means, but not scope of what source need to be provided.

Server and its mods are basically Program and its Libraries. And as using GPL code would "infect" the Program and other Libraries with GPL, same case applies to AGPL ... see https://www.fsf.org/bulletin/2021/fall/the-fundamentals-of-the-agplv3.

So if you are using AGPL mod, you are IMHO supposed to release source code of all mods and also of server (if it is built from modified source).

I'd guess with current situation you are vulnerable to possible legal action, although I think real risk of anybody doing that is fairly low....

In case of commercial mod - well, you can't combine them with AGPL on single server - you either break license of commercial (distributing all sources) or AGPL (not distributing all sources).

IANAL, but AGPL is "viral" similarly to GPL, except that user is not the one that has access to the binaries, but in case of AGPL user that connects via network (in this case a registered player on YL). AGPL changes only what "conveying" means, but not scope of what source need to be provided. Server and its mods are basically Program and its Libraries. And as using GPL code would "infect" the Program and other Libraries with GPL, same case applies to AGPL ... see https://www.fsf.org/bulletin/2021/fall/the-fundamentals-of-the-agplv3. So if you are using AGPL mod, you are IMHO supposed to release source code of all mods and also of server (if it is built from modified source). I'd guess with current situation you are vulnerable to possible legal action, although I think real risk of anybody doing that is fairly low.... In case of commercial mod - well, you can't combine them with AGPL on single server - you either break license of commercial (distributing all sources) or AGPL (not distributing all sources).

AGPL may cover in a viral way code that is included in the mod/library/program. But it does not affect other, bundled software which come with their own licenses.

Mods are no "libraries" compiled into a program. Even if:

https://www.gnu.org/licenses/gpl-faq.html#AGPLGPL

Imagine a webserver under a commercial license which allows plugins. Now they use such a plugin released under AGPL. That doesn't suddenly make the webserver infect with AGPL. But ofc they must release the plugin and any changes they make to it.

On the same server, I'm using nextcloud, which is also AGPL. That doesn't make the webserver or any other website have to become AGPL as well, even though nextcloud cannot be reached directly but offers its services via webserver, as much as a mod offers its code via MT server.

I'm also not a lawyer, so I can't be sure of whether my believes would hold up in court. Ofc, the chance to be sued over a MT mod is small, but since we try to be the good guys, we intend not to violate any license. There's an admin task to get rid of all AGPL licensed software due to the uncertainty that arises around this license: your-land/administration#173

Maybe also take a look here: https://medium.com/swlh/understanding-the-agpl-the-most-misunderstood-license-86fd1fe91275

All those faq regarding AGPL seem to emphasize that when something is compiled using AGPL code and AGPL-licensed code and other-licensed code are "inseparable", then maybe the whole derivative becomes AGPL. That's clearly not the case with MT. If you remove an AGPL mod, the server still works. Sure, it lacks the functionality, sure, there may be inconvenient unknown nodes, but still works.

AGPL may cover in a viral way code that is included in the mod/library/program. But it does not affect other, bundled software which come with their own licenses. Mods are no "libraries" compiled into a program. Even if: https://www.gnu.org/licenses/gpl-faq.html#AGPLGPL Imagine a webserver under a commercial license which allows plugins. Now they use such a plugin released under AGPL. That doesn't suddenly make the webserver infect with AGPL. But ofc they must release the plugin and any changes they make to it. On the same server, I'm using nextcloud, which is also AGPL. That doesn't make the webserver or any other website have to become AGPL as well, even though nextcloud cannot be reached directly but offers its services via webserver, as much as a mod offers its code via MT server. I'm also not a lawyer, so I can't be sure of whether my believes would hold up in court. Ofc, the chance to be sued over a MT mod is small, but since we try to be the good guys, we intend not to violate any license. There's an admin task to get rid of all AGPL licensed software due to the uncertainty that arises around this license: https://gitea.your-land.de/your-land/administration/issues/173 Maybe also take a look here: https://medium.com/swlh/understanding-the-agpl-the-most-misunderstood-license-86fd1fe91275 All those faq regarding AGPL seem to emphasize that when something is compiled using AGPL code and AGPL-licensed code and other-licensed code are "inseparable", then maybe the whole derivative becomes AGPL. That's clearly not the case with MT. If you remove an AGPL mod, the server still works. Sure, it lacks the functionality, sure, there may be inconvenient unknown nodes, but still works.
AliasAlreadyTaken added this to the Alias@work project 2023-05-20 12:07:45 +00:00

As long as all the authors of AGPL mods that are used here share your interpretation of the license, I guess you are safe from lawyers or similar trouble.

As long as all the authors of AGPL mods that are used here share your interpretation of the license, I guess you are safe from lawyers or similar trouble.

Again: The point is not to violate the license and get away with it. I want to comply with the license as written AND as intended.

Do you have any link or other information that backs your interpretation?

Again: The point is not to violate the license and get away with it. I *want* to comply with the license as written AND as intended. Do you have any link or other information that backs your interpretation?
Author
Member

i suppose, ultimately, the issue is yet to be decided in a court. https://tech.popdata.org/the-gpl-license-and-linking-still-unclear-after-30-years/

i suppose, ultimately, the issue is yet to be decided in a court. https://tech.popdata.org/the-gpl-license-and-linking-still-unclear-after-30-years/

So if neither the corporate guys nor the consultants nor the courts or the FSF can agree on something, how am I supposed to know what goes and what doesn't??

Sure, there's Alias' personal code of honour to comply with the spirit of the license, but noone can hold me acountable to that except me. I doubt it will hold up in court :P

This proves once again that (A)GPL was intended for an age of compilers, but is unfit for a tech and an age that with JIT, mods, plugins and other ways don't explicitly create a combined work, more a loosely coupled bunch of codes that are distinct works by themselves, but together create a greater thing. I may be mistaken, I am not a lawyer. I had hoped those who came up with those licenses might have been lawyers or at least consulted, but the impression they give is that they pulled it out of a bucket.

My takeaway is

  • The more choice of opensource licenses we have, the less we can cooperate
  • the SPIRIT of (A)GPL is good, the execution appears to be a mess
  • avoid viral licenses in general and AGPL in particular at all costs
  • take inventory of licenses and reimplement stuff that is licensed under AGPL

Known problems: worldedit, unified_inventory_plus, canned_food

I chose MIT, because I wanted to share stuff with as many people as possible, but I must accept there are people who have different ideas.

So if neither the corporate guys nor the consultants nor the courts or the FSF can agree on something, how am I supposed to know what goes and what doesn't?? Sure, there's Alias' personal code of honour to comply with the spirit of the license, but noone can hold me acountable to that except me. I doubt it will hold up in court :P This proves once again that (A)GPL was intended for an age of compilers, but is unfit for a tech and an age that with JIT, mods, plugins and other ways don't explicitly create a combined work, more a loosely coupled bunch of codes that are distinct works by themselves, but together create a greater thing. I may be mistaken, I am not a lawyer. I had hoped those who came up with those licenses might have been lawyers or at least consulted, but the impression they give is that they pulled it out of a bucket. My takeaway is - The more choice of opensource licenses we have, the less we can cooperate - the SPIRIT of (A)GPL is good, the execution appears to be a mess - avoid viral licenses in general and AGPL in particular at all costs - take inventory of licenses and reimplement stuff that is licensed under AGPL Known problems: worldedit, unified_inventory_plus, canned_food I chose MIT, because I wanted to share stuff with as many people as possible, but I must accept there are people who have different ideas.
Author
Member

if the AGPL is a problem, the GPL is also a problem if you ever want to release the code.

if the AGPL is a problem, the GPL is also a problem if you ever want to release the code.

There's a workaround against GPL becoming an issue: Not releasing. At least not as a "collection". In this case, we can release the YL mods under whatever license we want, but the "collection" doesn't get released and doesn't trigger GPL, as stupid as it sounds.

This workaround can't be applied to hosting a server, since that triggers AGPL, but not GPL.

So, in the best spirit sharing and working together, we must jump through some hoop. Fine with me, I'm more interested to share the YL mods than the list of repos that make up "the YL game".

The more I look at it, the more I get the impression those licenses achieved the opposite of what they want and what I want them to do.

I sincerely hope I'm mistaken somewhere and simply didn't understand something.

There's a workaround against GPL becoming an issue: Not releasing. At least not as a "collection". In this case, we can release the YL mods under whatever license we want, but the "collection" doesn't get released and doesn't trigger GPL, as stupid as it sounds. This workaround can't be applied to hosting a server, since that triggers AGPL, but not GPL. So, in the best spirit sharing and working together, we must jump through some hoop. Fine with me, I'm more interested to share the YL mods than the list of repos that make up "the YL game". The more I look at it, the more I get the impression those licenses achieved the opposite of what they want and what I want them to do. I sincerely hope I'm mistaken somewhere and simply didn't understand something.
Author
Member

the main problem is that lawyers are averse to potential liability.

only people who can afford lawyers worry about the potential problems due to the described "virality" of the (A)GPL. yes, the FSF's intention w/ those licenses is that anything that uses a library should have to also be released under the (A)GPL. but after reading a lot of legal arguments, i'm of the opinion that there's a huge problem w/ this.

the FSF doesn't get to decide what constitutes a derivative work - that's already defined by law and case law. it's arguable that compiling code into a single binary effectively creates a derivative work, but scripted code on its own would probably not be considered such under the law.

the fact that there's huge communities like that for the R programming language, where people freely license their stuff however they want even if it depends on GPL stuff, and no-one has taken anyone else to court, means to me that probably no-one besides richard stallman and a few others actually think the (A)GPL can mean that "library usage creates a derived work".

from what i understand, most non FSF lawyers that have chimed in on this argue against the FSF's position, but it's also certainly not unanimous. all the same, i wish i could convince you to take a view of this part of the problem the same way i do, but i also appreciate that you don't like the (A)GPL for other reasons entirely, and i certainly agree w/ you about some of them.

if i was running the server myself, and wanted to release the custom code under the MIT license at a future date, i would have no qualms about using AGPL mods. when i opted to use the AGPL for my mods myself, i absolutely interpreted it in a way that just meant "if you modify the code of the mod directly, and make that available on a public server, please release it so i can incorporate the good parts back into the original mod". i never would expect that the license would "spread" to other mods through dependencies.

the main problem is that lawyers are averse to potential liability. only people who can afford lawyers worry about the potential problems due to the described "virality" of the (A)GPL. yes, the FSF's intention w/ those licenses is that anything that uses a library should have to also be released under the (A)GPL. but after reading a lot of legal arguments, i'm of the opinion that there's a huge problem w/ this. the FSF doesn't get to decide what constitutes a derivative work - that's already defined by law and case law. it's arguable that compiling code into a single binary effectively creates a derivative work, but scripted code on its own would probably not be considered such under the law. the fact that there's huge communities like that for the R programming language, where people freely license their stuff however they want even if it depends on GPL stuff, and no-one has taken anyone else to court, means to me that probably no-one besides richard stallman and a few others actually think the (A)GPL can mean that "library usage creates a derived work". from what i understand, most non FSF lawyers that have chimed in on this argue against the FSF's position, but it's also certainly not unanimous. all the same, i wish i could convince you to take a view of this part of the problem the same way i do, but i also appreciate that you don't like the (A)GPL for other reasons entirely, and i certainly agree w/ you about some of them. if i was running the server myself, and wanted to release the custom code under the MIT license at a future date, i would have no qualms about using AGPL mods. when i opted to use the AGPL for my mods myself, i absolutely interpreted it in a way that just meant "if you modify the code of the mod directly, and make that available on a public server, please release it so i can incorporate the good parts back into the original mod". i *never* would expect that the license would "spread" to other mods through dependencies.

I admit I have no link to authoritative information in this way (authoritative would be some court decision and then there is question of jurisdiction, as some important aspects of copyright law are different across countries, so court decision from US may sometimes not be fully applicable within EU).

For mod, maybe the dependencies could be used as guide to when to release source is mandatory or not. If mod "worldedit_additions" has hard dependency on worldedit that is AGPL, I'd guess that worldedit_additions also needs to have source available, as the worldedit dependency is its core component.

If there is no dependency, then I guess maybe not.

If there is optional dependency ... hard to say :)

Also, for admin-only mods (only few people has access to worldedit), question is what is "conveying" - do you need to provide only people with actual access to the mod (i.e. the admin) the source, or everybody (even if they can't actually use the mod, because they lack the admin privs)?

where people freely license their stuff however they want even if it depends on GPL stuff, and no-one has taken anyone else to court

If the source is available, even though the conglomerate may technically be of some incompatible license or otherwise legally flawed, there is usually no or very little motivation for suing anybody for that.

I admit I have no link to authoritative information in this way (authoritative would be some court decision and then there is question of jurisdiction, as some important aspects of copyright law are different across countries, so court decision from US may sometimes not be fully applicable within EU). For mod, maybe the dependencies could be used as guide to when to release source is mandatory or not. If mod "worldedit_additions" has hard dependency on worldedit that is AGPL, I'd guess that worldedit_additions also needs to have source available, as the worldedit dependency is its core component. If there is no dependency, then I guess maybe not. If there is optional dependency ... hard to say :) Also, for admin-only mods (only few people has access to worldedit), question is what is "conveying" - do you need to provide only people with actual access to the mod (i.e. the admin) the source, or everybody (even if they can't actually use the mod, because they lack the admin privs)? > where people freely license their stuff however they want even if it depends on GPL stuff, and no-one has taken anyone else to court If the source is available, even though the conglomerate may technically be of some incompatible license or otherwise legally flawed, there is usually no or very little motivation for suing anybody for that.

The absence of lawsuits is no proof of the absence of breech of law!

Look at the douchebags who dig out some "law that is not acted upon" anymore, not because they want the law upheld, but because they don't like the person who committed the "crime".

Look at all the lawsuits where some company would be sued by a competitor not because anyone cared about them violating some rather unimportant clause, but to get rid of them.

Likewise, the presence of lawsuits doesn't proof a breech of law. See SCO vs Redhat. https://en.wikipedia.org/wiki/SCO%E2%80%93Linux_disputes

But the presence of lawsuits does proof a lot of money spent on things I don't want to spend money on. It takes ONE douchebag to cause trouble.

Your "If ONE of the mods is AGPL, the whole server must become AGPL and fully disclosed" holds up, I'll go PR a commit to worldedit. A fixed typo or something. As soon as I obtained part ownership, I'll sue the hell out of every server that doesn't fully AGPL their code. I very much doubt it works this way. Do you?

Unless any one of us is a lawyer, has insights into this topic, can provide real legal advice or at least a link to a related case that was not settled out of court, I may need to rethink my position. Until then we have no choice but to defend Your Land at least from the obvious misinterpretations a malicious actor could come up with.

German courts are not known for their technical expertise and due to my rejection of AGPL, I doubt some FSF or similar body would rush to my help.

I bet a real lawyer who reads up on my opinion cobbled together from long forgotten sources would die laughing.

The absence of lawsuits is no proof of the absence of breech of law! Look at the douchebags who dig out some "law that is not acted upon" anymore, not because they want the law upheld, but because they don't like the person who committed the "crime". Look at all the lawsuits where some company would be sued by a competitor not because anyone cared about them violating some rather unimportant clause, but to get rid of them. Likewise, the presence of lawsuits doesn't proof a breech of law. See SCO vs Redhat. https://en.wikipedia.org/wiki/SCO%E2%80%93Linux_disputes But the presence of lawsuits does proof a lot of money spent on things I don't want to spend money on. It takes ONE douchebag to cause trouble. Your "If ONE of the mods is AGPL, the whole server must become AGPL and fully disclosed" holds up, I'll go PR a commit to worldedit. A fixed typo or something. As soon as I obtained part ownership, I'll sue the hell out of every server that doesn't fully AGPL their code. I very much doubt it works this way. Do you? Unless any one of us is a lawyer, has insights into this topic, can provide real legal advice or at least a link to a related case that was not settled out of court, I may need to rethink my position. Until then we have no choice but to defend Your Land at least from the obvious misinterpretations a malicious actor could come up with. German courts are not known for their technical expertise and due to my rejection of AGPL, I doubt some FSF or similar body would rush to my help. I bet a real lawyer who reads up on my opinion cobbled together from long forgotten sources would die laughing.

Look at the douchebags who dig out some "law that is not acted upon" anymore, not because they want the law upheld, but because they don't like the person who committed the "crime".

True. Law, patents and copyright is often used as tool or weapon against others. Especially patent litigation can be costly to defend even in cases the claim is rubbish.

Your "If ONE of the mods is AGPL, the whole server must become AGPL and fully disclosed" holds up, I'll go PR a commit to worldedit. A fixed typo or something. As soon as I obtained part ownership, I'll sue the hell out of every server that doesn't fully AGPL their code. I very much doubt it works this way. Do you?

The PR has to be accepted and the servers will need to update to your version.
You can then sue anybody not complying with "your" license. But I can't predict result of such actions, especially if the underlying change you use to leverage the license would be tiny. But if you have good lawyer and you sue somebody that does not, you have good changes even with stupid accusations.

I think YL is not a rich cash cow that would attract such trolls looking for money, but is you ban some griefer, he may try to seek revenge this way.

IMHO very low risk, but not zero risk.

> Look at the douchebags who dig out some "law that is not acted upon" anymore, not because they want the law upheld, but because they don't like the person who committed the "crime". True. Law, patents and copyright is often used as tool or weapon against others. Especially patent litigation can be costly to defend even in cases the claim is rubbish. > Your "If ONE of the mods is AGPL, the whole server must become AGPL and fully disclosed" holds up, I'll go PR a commit to worldedit. A fixed typo or something. As soon as I obtained part ownership, I'll sue the hell out of every server that doesn't fully AGPL their code. I very much doubt it works this way. Do you? The PR has to be accepted and the servers will need to update to your version. You can then sue anybody not complying with "your" license. But I can't predict result of such actions, especially if the underlying change you use to leverage the license would be tiny. But if you have good lawyer and you sue somebody that does not, you have good changes even with stupid accusations. I think YL is not a rich cash cow that would attract such trolls looking for money, but is you ban some griefer, he may try to seek revenge this way. IMHO very low risk, but not zero risk.

I suppose it's worth considering the idea of virality a bit more.

If we have mods A, B, and C, where C depends on A and B and A and B have no dependencies, then C could potentially need to be AGPL to comply with licensing requirements if one of A or B is AGPL.

However: this virality can only propagate up a dependency tree. So, for example, A being AGPL does not require that B also be AGPL just because C uses both. This becomes obvious when you consider the scenario where A, B, and C have different copyright holders.

In this respect, I think it is safe to just AGPL release the mods which actually have the AGPL mods as dependencies. So, for example, this could be the top-level YL meta-mod, while the "meat" of YL's mods remain closed/proprietary for the time being. This would meet the conditions for AGPL licensing of the mods in question.

I suppose it's worth considering the idea of virality a bit more. If we have mods A, B, and C, where C depends on A and B and A and B have no dependencies, then C could potentially need to be AGPL to comply with licensing requirements if one of A or B is AGPL. **However:** this virality can only propagate *up* a dependency tree. So, for example, A being AGPL does not require that B also be AGPL just because C uses both. This becomes obvious when you consider the scenario where A, B, and C have different copyright holders. In this respect, I think it is safe to just AGPL release the mods which actually have the AGPL mods as dependencies. So, for example, this could be the top-level YL meta-mod, while the "meat" of YL's mods remain closed/proprietary for the time being. This would meet the conditions for AGPL licensing of the mods in question.

If the server and its mods would be viewed as single entity, using one agpl mod would cause all to be opensourced.

If mods would be seen as mostly independent entities running in common environment (the server), then using agpl mod will cause only the mod itself and any other mods that depends on it (directly or transitively) and any of that mods dependencies (direct or transitive)

But can't tell without lawyer which case from these two it is.

If the server and its mods would be viewed as single entity, using one agpl mod would cause all to be opensourced. If mods would be seen as mostly independent entities running in common environment (the server), then using agpl mod will cause only the mod itself and any other mods that depends on it (directly or transitively) and any of that mods dependencies (direct or transitive) But can't tell without lawyer which case from these two it is.

So for canned food example above, I'd expect that its direct dependencies would also be published (at least is they are modified):

default
vessels
flowers

and possibly also its indirect dependencies (unless those dependencies are added simply to enforce loading order or for a simple check of other mod's presence, thus being no real dependencies):

ethereal?
farming?
unified_inventory?

Legalese aside, I have done some experiments with tubelib on blocky and I found some disadvantages:

  • Pushers can push only horizontally, not up or down (unlike injectors).
  • Pushers can't be rotated with screwdrivers. Makes it hard to place sometimes with correct orientation without temporarily digging nearby wall.
  • Tubes sometimes autoconnect to machines you do not want even if you'd like to continue in different direction and connect elsewhere
  • Distributors are limited to 6 item types per output slot, which with inability of outputting up/down makes machine design take more space (several chained distributors)

So in general, more space (sometimes significantly) would be needed for a machine performing same task than comparable pipeworks-based machine

There are also some advantages - pushers do not need mese clock signal like injectors do, they push by themselves.

So for canned food example above, I'd expect that its direct dependencies would also be published (at least is they are modified): **default** **vessels** **flowers** and possibly also its indirect dependencies (unless those dependencies are added simply to enforce loading order or for a simple check of other mod's presence, thus being no real dependencies): **ethereal?** **farming?** **unified_inventory?** Legalese aside, I have done some experiments with tubelib on blocky and I found some disadvantages: * Pushers can push only horizontally, not up or down (unlike injectors). * Pushers can't be rotated with screwdrivers. Makes it hard to place sometimes with correct orientation without temporarily digging nearby wall. * Tubes sometimes autoconnect to machines you do not want even if you'd like to continue in different direction and connect elsewhere * Distributors are limited to 6 item types per output slot, which with inability of outputting up/down makes machine design take more space (several chained distributors) So in general, more space (sometimes significantly) would be needed for a machine performing same task than comparable pipeworks-based machine There are also some advantages - pushers do not need mese clock signal like injectors do, they push by themselves.

One pattern that I use involves loading items from centralized storage into different machines. I achieve this by altering teleport tube channels on the fly (via digilines). This cannot be done with techpack currently.

Use pushers to send it to some central container, select which item via mesecon signals (would need to do one item per storage location though); from there activate the right pusher to place the item in the desired output location.

Optionally you can use detectors if you want a specific number of items.

Tubes sometimes autoconnect to machines you do not want even if you'd like to continue in different direction and connect elsewhere

Sneak+place to make it not autoconnect.

Pushers can't be rotated with screwdrivers. Makes it hard to place sometimes with correct orientation without temporarily digging nearby wall.

Should be a fairly simple edit to allow screwdrivers to work properly with it.

Tubelib setups will generally be larger yes, however tubes will never break and leak your precious stuff all over, it's much less laggy for both the server and clients around it, and items "travel" instantly so there's no chance or way for them to get lost or destroyed.

For stuff like item transport (via teleporters) from a mining trip, you can simply leave a bunch of unconnected teleporters back at your base and connect to them while you're out.

> One pattern that I use involves loading items from centralized storage into different machines. I achieve this by altering teleport tube channels on the fly (via digilines). This cannot be done with techpack currently. Use pushers to send it to some central container, select which item via mesecon signals (would need to do one item per storage location though); from there activate the right pusher to place the item in the desired output location. Optionally you can use detectors if you want a specific number of items. > Tubes sometimes autoconnect to machines you do not want even if you'd like to continue in different direction and connect elsewhere Sneak+place to make it not autoconnect. > Pushers can't be rotated with screwdrivers. Makes it hard to place sometimes with correct orientation without temporarily digging nearby wall. Should be a fairly simple edit to allow screwdrivers to work properly with it. Tubelib setups will generally be larger yes, however tubes will never break and leak your precious stuff all over, it's much less laggy for both the server and clients around it, and items "travel" instantly so there's no chance or way for them to get lost or destroyed. For stuff like item transport (via teleporters) from a mining trip, you can simply leave a bunch of unconnected teleporters back at your base and connect to them while you're out.

We should have split off the legal discussion and the feature discussion.

@sixer : Regarding canned_food, I think you mix up what depends on which. default does NOT depend on canned_food. default doesn't know of canned_food. Only stuff that depends on cann_food knows of canned_food, not the other way round.

Again:

Unless any one of us is a lawyer, has insights into this topic, can provide real legal advice or at least a link to a related case that was not settled out of court, I may need to rethink my position. Until then we have no choice but to defend Your Land at least from the obvious misinterpretations a malicious actor could come up with.

Read: We need to get rid of AGPL, then there will be no lawyer necessary.

Ofc we'll still share our stuff, but on terms others find less legally challenging.

We should have split off the legal discussion and the feature discussion. @sixer : Regarding canned_food, I think you mix up what depends on which. default does NOT depend on canned_food. default doesn't know of canned_food. Only stuff that depends on cann_food knows of canned_food, not the other way round. Again: > Unless any one of us is a lawyer, has insights into this topic, can provide real legal advice or at least a link to a related case that was not settled out of court, I may need to rethink my position. Until then we have no choice but to defend Your Land at least from the obvious misinterpretations a malicious actor could come up with. Read: We need to get rid of AGPL, then there will be no lawyer necessary. Ofc we'll still share our stuff, but on terms others find less legally challenging.

We should have split off the legal discussion and the feature discussion.

If AGPL would be a show-stoper, then the feature discussion may become pointless (with tubelib and techpack unusable and pipeworks being the one to be replaced ... is there any other tube-providing mod?)

Technically, there is about 3 years old version of techpack that is not AGPL, but I won't suggest using it (according to commit message it is for MT before 5.3 and may need possibly lot of fixing to be usable with current MT)

@sixer : Regarding canned_food, I think you mix up what depends on which. default does NOT depend on canned_food. default doesn't know of canned_food. Only stuff that depends on cann_food knows of canned_food, not the other way round.

cann_food needs default -> cann_food and default forms a conglomerate that needs to be opensourced due to AGPL -> default needs to be opensourced due to AGPL. The AGPL "infection" can spread both ways in the dependency tree, by depending and being dependent.

> We should have split off the legal discussion and the feature discussion. If AGPL would be a show-stoper, then the feature discussion may become pointless (with tubelib and techpack unusable and pipeworks being the one to be replaced ... is there any other tube-providing mod?) Technically, there is about 3 years old version of techpack that is not AGPL, but I won't suggest using it (according to commit message it is for MT before 5.3 and may need possibly lot of fixing to be usable with current MT) > @sixer : Regarding canned_food, I think you mix up what depends on which. default does NOT depend on canned_food. default doesn't know of canned_food. Only stuff that depends on cann_food knows of canned_food, not the other way round. cann_food needs default -> cann_food and default forms a conglomerate that needs to be opensourced due to AGPL -> default needs to be opensourced due to AGPL. The AGPL "infection" can spread both ways in the dependency tree, by depending and being dependent.

We should have split off the legal discussion and the feature discussion.

I agree.

@AliasAlreadyTaken Please take a look at my earlier comment. In general, if a YL mod does not depend on the source of an AGPL mod, then its use in the server definitely does not impact your eligibility for AGPL licensing.

I do not think there are any mods running on the server that actually use canned_food or worldedit as dependencies (aside from, possibly, a top-level modpack that imports all of the server's mods). As such, there is no real licensing issues here.

cann_food needs default -> cann_food and default forms a conglomerate that needs to be opensourced due to AGPL -> default needs to be opensourced due to AGPL. The AGPL "infection" can spread both ways in the dependency tree, by depending and being dependent.

@sixer This is wrong on multiple levels. Licenses are not contracts. Nobody that uses AGPL code in a derivative work is required to open-source their code. The AGPL is a license, so if someone uses AGPL code without meeting the criteria of the AGPL, they are simply using the code without a license. This is akin to software piracy - it's a copyright violation.

The only question here is whether some, or all of YL mods are derivative works of the AGPL mods running on the server. So, for example, if we removed worldedit, would it break a YL mod? I think.the answer is no, so it is safe to use worldedit. Same goes for canned_food, etc.

Just because two mods both run on the same server, doesn't mean one is a derivative work of another.

> We should have split off the legal discussion and the feature discussion. I agree. @AliasAlreadyTaken Please take a look at my earlier comment. In general, if a YL mod does not depend on the source of an AGPL mod, then its use in the server *definitely* does not impact your eligibility for AGPL licensing. I do not think there are any mods running on the server that actually use canned_food or worldedit as dependencies (aside from, possibly, a top-level modpack that imports all of the server's mods). As such, there is no real licensing issues here. > cann_food needs default -> cann_food and default forms a conglomerate that needs to be opensourced due to AGPL -> default needs to be opensourced due to AGPL. The AGPL "infection" can spread both ways in the dependency tree, by depending and being dependent. @sixer This is wrong on multiple levels. *Licenses are not contracts*. Nobody that uses AGPL code in a derivative work is required to open-source their code. The AGPL is a license, so if someone uses AGPL code without meeting the criteria of the AGPL, they are simply using the code without a license. This is akin to software piracy - it's a copyright violation. The only question here is whether some, or all of YL mods are derivative works of the AGPL mods running on the server. So, for example, if we removed worldedit, would it break a YL mod? I think.the answer is no, so it is safe to use worldedit. Same goes for canned_food, etc. Just because two mods both run on the same server, doesn't mean one is a derivative work of another.

@Dirac

Case1: Mod B is licensed under AGPL. Mod A needs to have a dependency on mod B, if it wants to define a crafting recipe that has an ingredient defined in mod B.

There is a construction like "if mod B is present, then add the recipe", in Minetest terms this is an "optional dependency".

There is also the construction to (hard) depend on mod B, read: A cannot load when B is not present.

According to you, both cases would trigger AGPL and force mod A be AGPL, too?

Case2: Mod B is licensed under AGPL. Mod B is part of a mod collection which is used on a server. Take away mod B and the server still runs, but ofc lacks the functionality of mod B.

According to you, this case would not force AGPL on the mod collection?

@Dirac Case1: Mod B is licensed under AGPL. Mod A needs to have a dependency on mod B, if it wants to define a crafting recipe that has an ingredient defined in mod B. There is a construction like "if mod B is present, then add the recipe", in Minetest terms this is an "optional dependency". There is also the construction to (hard) depend on mod B, read: A cannot load when B is not present. According to you, both cases would trigger AGPL and force mod A be AGPL, too? Case2: Mod B is licensed under AGPL. Mod B is part of a mod collection which is used on a server. Take away mod B and the server still runs, but ofc lacks the functionality of mod B. According to you, this case would not force AGPL on the mod collection?

@AliasAlreadyTaken To be clear, you are never forced do license your code some way just because of a dependency on a copyleft license. If you don't meet the criteria of a copyleft license, then you are using the code without a license, which is simple copyright infringement.

Anyways: in case 2 there is definitely no concern and you meet the conditions for being licensed to use mod B under the AGPL. In case 1, someone could argue that the optional dependency constitutes a derivative work. However, there is an easy workaround for this: create a separate stub mod that contains the optional dependency code (e.g. crafting recipe addition). Then, you can release this stub mod under the AGPL and not worry about licensing issues.

@AliasAlreadyTaken To be clear, you are never *forced* do license your code some way just because of a dependency on a copyleft license. If you don't meet the criteria of a copyleft license, then you are using the code without a license, which is simple copyright infringement. Anyways: in case 2 there is definitely no concern and you meet the conditions for being licensed to use mod B under the AGPL. In case 1, someone *could* argue that the optional dependency constitutes a derivative work. However, there is an easy workaround for this: create a separate stub mod that contains the optional dependency code (e.g. crafting recipe addition). Then, you can release this stub mod under the AGPL and not worry about licensing issues.

We do NOT want to infringe a copyright. That's entirely out of the question! If someone releases their stuff under a hostile license and we still use it, then we must respect the written and intended rules of that license.

I only need to know what those rules are, in a clear and understandable way. Only then I can decide whether to throw out the mod or reimplement or make a stub mod or anything.

I do NOT want to cheat the creator of the mod out of his legit wishes he made clear by choosing a license. He chose that license for reasons unknown to me, so all I have is the intention and text of that license. AGPL is not reversible, so both he and I must live with his decision. It is very OK if he decides to release under AGPL and it is also very OK if therefore I choose not to use his mod on my server.

As said before, this is my takeaway: To avoid headache, remove all AGPL mods.

Unfortunately this means, tubelib is not for us, even if it had nice features we cannot use it due to licensing.

Sure, we could go back in history and fork from a non-AGPL commit, then try to fix all bugs ourselves. Not only would that be a huge undertaking, but also it would be cheating: Someone released the code of tubelib under AGPL and we will respect this wish. He found his reasons important enough to relicense the mod, so I will honour his wish and not use it.

Edit: One more thing: This means, even if we remove or reimplement all AGPL mods, we still cannot publish mod A, because it has optional dependencies on GPL or LGPL licensed mods, making it - under your premise - forced-GPL, too. Except, if we never release it. Yay. I very much doubt that helps MT as a whole as we intended.

We do NOT want to infringe a copyright. That's entirely out of the question! If someone releases their stuff under a hostile license and we still use it, then we must respect the written and intended rules of that license. I only need to know what those rules are, in a clear and understandable way. Only then I can decide whether to throw out the mod or reimplement or make a stub mod or anything. I do NOT want to cheat the creator of the mod out of his legit wishes he made clear by choosing a license. He chose that license for reasons unknown to me, so all I have is the intention and text of that license. AGPL is not reversible, so both he and I must live with his decision. It is very OK if he decides to release under AGPL and it is also very OK if therefore I choose not to use his mod on my server. As said before, this is my takeaway: To avoid headache, remove all AGPL mods. Unfortunately this means, tubelib is not for us, even if it had nice features we cannot use it due to licensing. Sure, we could go back in history and fork from a non-AGPL commit, then try to fix all bugs ourselves. Not only would that be a huge undertaking, but also it would be cheating: Someone released the code of tubelib under AGPL and we will respect this wish. He found his reasons important enough to relicense the mod, so I will honour his wish and not use it. Edit: One more thing: This means, even if we remove or reimplement all AGPL mods, we still cannot publish mod A, because it has optional dependencies on GPL or LGPL licensed mods, making it - under your premise - forced-GPL, too. Except, if we never release it. Yay. I very much doubt that helps MT as a whole as we intended.
Author
Member

Btw flux your server crashed with tubelib liquid sampler powering on. Since Alias doesn't want me communicating on Your Land, noting this here (?)

better to post such things to #4132, or even better, https://github.com/fluxionary/minetest-fluxtest/issues (looks like you posted there already).

LGPL

let's move discussion of licenses somewhere else, this issue has gotten totally side-tracked.

> Btw flux your server crashed with tubelib liquid sampler powering on. Since Alias doesn't want me communicating on Your Land, noting this here (?) better to post such things to #4132, or even better, https://github.com/fluxionary/minetest-fluxtest/issues (looks like you posted there already). > LGPL let's move discussion of licenses somewhere else, this issue has gotten totally side-tracked.

[...] Since Alias doesn't want me communicating on Your Land, [...]

@niceride This claim has no basis in reality. I must ask you to refrain from spreading lies like this.

> [...] Since Alias doesn't want me communicating on Your Land, [...] @niceride This claim has no basis in reality. I must ask you to refrain from spreading lies like this.

[...] Since Alias doesn't want me communicating on Your Land, [...]

@niceride This claim has no basis in reality. I must ask you to refrain from spreading lies like this.

Notice the date, this was literally when I was banned from speaking on Your Land and you advised me not to communicate on Your Land. I will allow you the opportunity to correct your statement.

You were advised not to go around the jail by talking via IRC. Do not make it appear like you were "banned from speaking" for no reason. You were in jail because of things you said to a player and you kept insulting them from the chatbridge/IRC.

If you think I treated you unfairly, please report me. No joke, on YL you can do that and we will investigate it like every other report. That's where we will handle this matter and NOT on some unrelated issue.

> > > [...] Since Alias doesn't want me communicating on Your Land, [...] > > > > @niceride This claim has no basis in reality. I must ask you to refrain from spreading lies like this. > > Notice the date, this was literally when I was banned from speaking on Your Land and you advised me not to communicate on Your Land. I will allow you the opportunity to correct your statement. You were advised not to go around the jail by talking via IRC. Do not make it appear like you were "banned from speaking" for no reason. You were in jail because of things you said to a player and you kept insulting them from the chatbridge/IRC. If you think I treated you unfairly, please report me. No joke, on YL you can do that and we will investigate it like every other report. That's where we will handle this matter and NOT on some unrelated issue.

You were advised not to go around the jail by talking via IRC. Do not make it appear like you were "banned from speaking" for no reason. You were in jail because of things you said to a player and you kept insulting them from the chatbridge/IRC.

I'm not sure what else to say other than your insistence on commenting about this on an unrelated public bug tracker is misguided, and the content of what you are saying is incorrect (as a re-reading of the relevant logs shows).

If you think I treated you unfairly, please report me. No joke, on YL you can do that and we will investigate it like every other report. That's where we will handle this matter and NOT on some unrelated issue.

Alias, it is off-topic for this ticket. Flux and I got into contact long ago as suggested via this ticket (despite the communications blockade against me) and resolved the issue we discovered while testing tubelib on their server. I can't imagine a world in which what you've written is appropriate for the circumstances nor supported by any bent of the factual information so I will choose to ignore it. I will remove myself from this discussion and any contributions to this ticket accordingly.

> You were advised not to go around the jail by talking via IRC. Do not make it appear like you were "banned from speaking" for no reason. You were in jail because of things you said to a player and you kept insulting them from the chatbridge/IRC. I'm not sure what else to say other than your insistence on commenting about this on an unrelated public bug tracker is misguided, and the content of what you are saying is incorrect (as a re-reading of the relevant logs shows). > > If you think I treated you unfairly, please report me. No joke, on YL you can do that and we will investigate it like every other report. That's where we will handle this matter and NOT on some unrelated issue. Alias, it is off-topic for this ticket. Flux and I got into contact long ago as suggested via this ticket (despite the communications blockade against me) and resolved the issue we discovered while testing tubelib on their server. I can't imagine a world in which what you've written is appropriate for the circumstances nor supported by any bent of the factual information so I will choose to ignore it. I will remove myself from this discussion and any contributions to this ticket accordingly.

Since this has no chance of being resolved, we'll close it. If the situation changes, we may reopen. If a new/better pipeworks replacement shows up, we'll open a new issue.

Techpak: Wontfix.

Since this has no chance of being resolved, we'll close it. If the situation changes, we may reopen. If a new/better pipeworks replacement shows up, we'll open a new issue. Techpak: Wontfix.
AliasAlreadyTaken added the
5. result/wontfix
label 2023-11-19 08:50:46 +00:00
AliasAlreadyTaken removed this from the Alias@work project 2023-11-19 08:50:50 +00:00
flux changed title from replace tubelib w/ techpack to replace pipeworks w/ techpack 2023-11-23 20:25:53 +00:00
Sign in to join this conversation.
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: your-land/bugtracker#4514
No description provided.