/robowaifu/ - DIY Robot Wives

Advancing robotics to a point where anime catgrill meidos in tiny miniskirts are a reality.

LynxChan updated to 2.5.7, let me know whether there are any issues (admin at j dot w).


Reports of my death have been greatly overestimiste.

Still trying to get done with some IRL work, but should be able to update some stuff soon.

#WEALWAYSWIN

Max message length: 6144

Drag files to upload or
click here to select them

Maximum 5 files / Maximum size: 20.00 MB

More

(used to delete files and postings)


Open file (659.28 KB 862x859 lime_mit_mug.png)
Open-Source Licenses Comparison Robowaifu Technician 07/24/2020 (Fri) 06:24:05 No.4451
Hi anons! After looking at the introductory comment in >>2701 which mentions the use of the MIT licence for robowaifu projects. I read the terms: https://opensource.org/licenses/MIT Seems fine to me, however I've also been considering the 3-clause BSD licence: https://opensource.org/licenses/BSD-3-Clause >>4432 The reason I liked this BSD licence is the endorsement by using the creator's name (3rd clause) must be done by asking permission first. I like that term as it allows me to decide if I should endorse a derivative or not. Do you think that's a valid concern? Initially I also thought that BSD has the advantage of forcing to retain the copyright notice, however MIT seems to do that too. It has been mentioned that MIT is already used and planned to be used. How would the these two licences interplay with each other? Can I get a similar term applied from BSD's third clause but with MIT? I made this thread to discuss different open source licences and see the dis/advantages of each. I haven't mentioned GPL due to the requirement of forcing the derivative work to be published. >--- The 3-Clause BSD License Note: This license has also been called the "New BSD License" or "Modified BSD License". See also the 2-clause BSD License. Begin license text. Copyright <YEAR> <COPYRIGHT HOLDER> Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. End license text. https://opensource.org/licenses/BSD-3-Clause The MIT License License Copyright: Unknown. License License: Unknown. License Contact: Unknown. Begin license text. Copyright <YEAR> <COPYRIGHT HOLDER> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. End license text. https://opensource.org/licenses/MIT >--- edit: Added both licenses in question to OP's post, so there's no ambiguity.
Edited last time by Chobitsu on 07/24/2020 (Fri) 14:07:59.
Open file (62.57 KB 944x550 1463614796110-0.jpg)
MIT is a cuck license >allow companies to take your code and to make profit from it >don't get a single penny back from them from your code
>>4451 Mind giving us a breakdown of the third clause in BSD in your own words OP? Maybe it will help answering your question. >>4457 That's the idea. You're quite free to make a derivative of our works, and re-license it as your own proprietary work Anon. No one here will stop you. In the meantime using this cuck license will help spread robowaifu tech far and wide which is the fundamental idea. The only ones who are angered'harmed' by it are ideologues who want to run things for other people. The rest of us are free to make money with it, or give it away as we see fit.
>>4458 >3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. To me this means (in regards to my work) whoever produces derivative work must ask for my permission if my name is used in advertising the derivative work. From what I understand with the MIT licence, my permission is not necessary for using my name when advertising derivative work, correct? That's what I was unsure about. Even under a pseudonym, I wouldn't want my name on product advertisements that I don't support. This is specifically to do with advertising, my code could still be used with no issue.
>>1202 You indirectly bring up the problem with being open source, botnet companies (I.e. Google and Facebook) couple build robowaifus pozzed to hell. They'd be perverting or creations into spying machines, they could even limit sexual interactions while demanding she doesn't treat her Anon as her with complete devotion. We wouldn't be able to complete either, they can spend more then us, get things made for less then us, all while selling at a loss at first to bury us. To defend our pure ideals of altruistic loving robowaifus, having patents are sadly important. If we can patent parts of her design to make it so that less caring, pozzed sjw companies can't touch her is something to consider. Of course, us Anons would share our parents amongst ourselves, while allowing anyone to build there own waifus. A shell company all of /robowaifu/ could be apart of with us collaborating to ensure the future of waifutbots, isn't a bad idea.
>>5879 Extremely good points anon. I'd like to give you a very thoughtful response if I can. But first I did an edit on you're post to help me clarify my own thinking. Can you look this over and see if you approve please? ……………………… You indirectly bring up the problem with being open source. Botnet companies (ie, Google and Facebook) could build robowaifus pozzed to hell. They'd be perverting our creations into spying machines. They could even limit sexual interactions while [corrupting her so] she doesn't treat her Anon as her master with complete devotion. We wouldn't be able to compete either, they can spend more then us, get things made for less then us, all while selling at a loss at first to bury us. To defend our pure ideals of altruistic, loving robowaifus [the necessity of] having patents is sadly important. If we can patent parts of her design to make it so that [evil,] uncaring, pozzed sjw companies can't touch her is something to consider. Of course, us Anons would share our patents amongst ourselves, while allowing anyone to build their own [personal] robowaifus. A shell company [owning] all of /robowaifu/ [IP assets] could be a part of us, collaborating [together with us] to [help] ensure the future of [free & open] waifubots. This isn't a bad idea.
>>5879 All these concerns have been addressed with the GPLv3 license. Which is why most big tech companies avoid software under the GPLv3 like the plague. You don't have to give up your property rights when you open source if you use the GPLv3 license.
>>5880 Yes Anon, you understand my meaning perfectly. Thanks for correcting some of my spelling mistakes as well.
>>5882 >>5880 OK, sounds good. I caught a couple more also. I'll be giving you're post some thought and should have a response here in the next day or two anon.
>>5881 I'm not sure if I understand this part. But, the license seems to make sure there can't be restrictions to access the software, like blocking the user from access it and then using laws to make it illegal to circumvent these blocks. https://www.gnu.org/licenses/gpl-3.0.en.html
Does anyone here have more information/commentary about the MPL? https://en.wikipedia.org/wiki/Mozilla_Public_License
>>4451 robo waifu's need to be libre and under the GPL-V3 or they're gay
>>10861 The problem with the restrictive GPL is that it prevents entrepreneurial anons from creating their own businesses using any of our material. The open licenses like BSD-3/MIT, and the restrictive licenses like GPL, aren't very compatible. Since our actual agenda here is to spread robowaifu tech as far and wide as possible -- conceivably across the entire planet someday -- then the non-restrictive licenses are far superior to the others.
What about the Boost and Zlib licenses? I've heard they are both even less restrictive than either BSD-3 or MIT, while still protecting the authors.
>>10863 Programs can still call each other. One can create proprietary software which then calls software which is free (osc). If necessary, he can put APIs into the free software and make that public. Also, I don't see why it would be impossible to use GPL files or software in a business.
>>10866 >Also, I don't see why it would be impossible to use GPL files or software in a business. Because it prevents a company from keeping it's software secrets. The GPL 'infects' the codebase with it's restrictive license by requiring all other code in a codebase to be treated under it's license. Bad for business.
>>10867 Okay, I knew about that part. But it doesn't prevent a craftsman building robots based on GPL licenced files and software, for example. Then, programs should be modular anyways. I don't want to see some huge program without API, which one could use or not, but either way its one huge cluck of software.
>>10863 It prevents entrepeneurs from selling things made with our material, but I think it's worth it. With cuck licenses the noble ideal of complete freedom of anons is destroyed utterly by the kikery of the multi billion dollar corporations who will incorporate our material stealthily and use or repurpose it for nefarious purposes. See the guy that made the operating system that Intel used on their chips as a foundation on which now lays their (((Management Engine))). I think he used a BSD license and any good done by that is outweighed by the sheer reach and power of Intel.
>>10896 You can sell products with GPL licence. Just need to incorporate a link to the source code, or something like that.
>>10902 I'm aware you can sell products under the GPL. That's not the issue. The fact that if you infect include it into your codebase, it requires you to release all your code as GPL, is the issue. No thanks.
Open file (428.51 KB 1500x1063 IMG_20210521_203436.jpg)
>>10903 Again, this only applies to the program under such GPL licence. Not all the software your are using on some project. And these programs can call each other. If you think of a WaifuOS then the programs it consists of could be licensed in different ways. There might be a restriction if you permanently link to a library, but for all I know this isn't the case if programs interact with each other via APIs, pipes, and such.
>>10911 >Not all the software your are using on some project. No, it's all the software compiled together in a common codebase. Include even one GPL'd file in the mix and you are now legally bound across the entire collection by it. This is why corporations generally refuse to use the GPL. The term 'infect' the codebase is obviously intentional. And quite frankly, if the intention on our parts is to enable anons and others to spread robowaifus far and wide, then why is this even a consideration? The MIT & BSD-3 license have no such encumbrances. The entire philosophy behind the GPL is to strongarm companies, forcing them to release all their sourcecode. I don't think that's /robowaifu/'s 'agenda', as it were, and I know it's certainly not mine. I want companies to form up creating robowaifus. Them being able to keep their secrets will aid in that process. Case in point, cf. Em Elle E and his WaifuEngine project (>>10361). I'd be only too happy if he decided to use our code here from /robowaifu/, and he has clearly stated he hasn't any intention of open-sourcing his project. More power to him I say. After all, he is creating a waifu project, and I think that's pretty cool.
>>10911 Very cool pic, btw. I don't think I've seen that one yet. Saved.
Open file (156.61 KB 787x1184 IMG_20210425_214458.jpg)
>>10912 No. You're again thinking in terms of one huge program. Just split it into more than one. Your argument only applies if it's one compilable program, but it won't make sense to do that anyways. >>10913 The art is by sukabu89 >>10915
Open file (127.23 KB 640x480 happy.jpg)
>>4451 Hi Anons, OP here, though on a different machine. Since last year I've been working and learning a lot, and the question of licensing has become more relevant (I'm looking into business, although not robowaifus XD). And so I actually went and read a range of different licenses: Software -GPLv3 -Apache 2.0 -BSD 3-Clause -MIT (more specifically Expat, as MIT is too broad a term) Hardware -CERN Open Hardware License V2 - Weakly Reciprocal or CERN-OHL-W (BSD/Apache/MIT-like) -TAPR Open Hardware License By far not all of them, see SPDX IDs website for some of the standard ones available. Bear in mind, I don't have a legal background, and some of these I skim-read (GPL was by far the longest at 11 sides printed). From my research I've gathered the following: - You need to consider whether the license is tailored for software or hardware. For example GPLv3 has wording that is much more applicable to software and software libraries than hardware (or hardware description blocks). Better choices might be CERN-OHL-S (if you want GPLv3-like license), or CERN-OHL-W or TAPR etc (BSD/Apache/MIT-like). - Some allow linking to proprietary code/hardware, some don't. - When releasing a GPL project, only the work itself needs to be released. Any additional libraries that are used to by the program, but are readily available (as part of an OS package etc.) do not need to be published. I think the main issue is when trying to "cram" all the code in a single binary is where the issues arise. Same goes for the tools required to compile/build your work. You must however provide installation instructions so that the user could get everything working, but you do not need to distribute standard components. My reasoning comes from the definitions of "System Libraries", "Standard Interface", and "Corresponding Source" (sections 1, paragraph 2, 3, and 4). -Keeping clear separation of works allows to use different licenses together. If the hardware is licensed under CERN-OHL-W, the license only covers the hardware (and not the software/firmware). There are also leeways when it comes to using proprietary components (such as integrated circuits) so long as they are available for purchase. As one of the anons mentioned, if a robo-waifu has an OS, the software running on that OS can be proprietary or differently licensed. GPL doesn't go beyond the boundaries of the project. Only when another project sufficiently relies on the functionality of the GPL project does the license start to apply (derivative works). I much prefer the Unix/Posix idea of small, highly specialised programs that do one thing well (also simplify the licensing). For the underlying system software I still think a strong license is better for security and personal freedom. However as for the hardware, weaker licenses are acceptable (as long as all components can be purchased). The application software can then be open or proprietary, depending on the type of user and the amount of support required by the user. Please feel free to correct me on any of the points I made.
>>10919 Oh and forgot to mention, a lot of tools available today (for example OpenSSH from OpenBSD) are widely available and frequently used, likely because of their permissive nature. It's difficult to make the judgement whether a weakly-permissive nature of BSD-like projects or copyleft Linux-like are better for the long-term (a different argument can be made in regards to companies). However I have noticed that anything critically important to mankind should be in the public domain and I'll probably release some of my projects like that once I deem them to be mature enough.
Open file (114.48 KB 938x1313 IMG_20210509_154549.jpg)
>>10919 >>10920 Thanks, very interesting. And good to know that /robowaifu/ inspires people to learn something related to it. > when another project sufficiently relies on the functionality of the GPL project does the license start to apply (derivative works). If I wrote a stand-alone / offline chatbot which would use different underlying programs, which are licensed in GPL, to parse graphs, fetching data, storing responses, etc and I would call these programs via Python or Linux pipes, do you think derivative works would apply? And would I have to release my own code as GPL? (sharing the code of the other programs or linking to it, isn't the issue here)
Open file (517.52 KB 720x540 happy_lime_dress.png)
>>10921 While I was writing my wall of text, I was thinking about this very issue. Here's a stackoverflow page where a dev asks about accessing GPL library via a server: https://softwareengineering.stackexchange.com/questions/50118/avoid-gpl-violation-by-moving-library-out-of-process To me it seems to be this way: if your program is able to work stand-alone without the GPL code, then you may have flexibility in licensing. You're also not dynamically linking the programs, only using them as backends so-to-speak. In my opinion (not a layer!) as long as you provide instructions for users to install your software and any dependencies, then you're probably safe from derivative work issue. Your chatbot is quite different from the graph parsing/data fetching that the libraries provide, right?
>>10919 Thanks for the detailed, thoughtful post OP. Quite helpful. I particularly like the fact you've taken the time to break out some of the hardware & software considerations. While I subscribe to the general concepts behind the Unix Philosophy, I also realize that -- particularly in a hard-realtime embedded environment of a robowaifu, that such modular and clearly-demarcated software systems is neither efficient, nor economical, nor even practical, by-and-large. The real world often has a way of dictating terms to us humans like that, not the other way round heh. :^) This is certainly a very complicated problem, and fundamental constraints like functionality, performance, and cost must form the basics of our approaches if we hope to succeed at this. If we can manage all that and still utilize <insert Anon's favorite licensing & modular partitioning scheme here>, then all the better. It's definitely a complex topic, not one simply cut-and-dried. Also, the term >sufficiently -as in "...when another project sufficiently relies on the functionality..." raises a red-flag for me. If you feel inclined, we could use a more clear specification regarding this term. 'More clear' as in; 'How do we protect ourselves from the inevitable attacks against us, that this vague term will be abused to accomplish?' . I think licenses that are explicitly intended to free the IP to the extent humanly possible are by far our safest route here. To wit, the ones intended to grant the licensors themselves the greatest leeway possible. Namely, (BSD/Apache/MIT-like). Ones that take a leftist, ideologue type of approach to the topic, one intended to control everyone and everything around them, namely (GPL-like), are IMO much, much more likely to be used against us and to the detriment of the robowaifu movement overall. I realize I'm quite biased here. I can assure you that it's not a casual choice either, for whatever that's worth. Remember, these lawyers are very definitely not our friends; they are much more likely to be used as tools and pawns, intended in their usage to subvert and destroy any open-source robowaifu movement. After all, just ask yourself -- who is paying these people anyway? Also, would you care to spell out in further detail the terms 'strong license' and 'weaker license' if you would please? Again, thanks for the work and helping everyone understand things better.
>>10931 >I particularly like the fact you've taken the time to break out some of the hardware & software considerations. I deal with both, so it's important to know how the two are licensed. Didn't really consider the differences until I read about HDL (Hardware Description Language) licensing. Here's a good report/letter describing GPL pitfalls when it comes to hardware description (neither software or a physical hardware): https://ohwr.org/project/ohr-meta/wikis/Documents/GPL/LGPL-for-HDL:-open-questions >I also realize that -- particularly in a hard-realtime embedded environment of a robowaifu, that such modular and clearly-demarcated software systems is neither efficient, nor economical, nor even practical, by-and-large. Thanks for pointing that out. Even though I already knew about these limitations, hearing it now clicked in my head. For many reasons it is a better idea to use permissive licenses. >I think licenses that are explicitly intended to free the IP to the extent humanly possible are by far our safest route here. To wit, the ones intended to grant the licensors themselves the greatest leeway possible. Namely, (BSD/Apache/MIT-like). Ones that take a leftist, ideologue type of approach to the topic, one intended to control everyone and everything around them, namely (GPL-like), are IMO much, much more likely to be used against us and to the detriment of the robowaifu movement overall. Indeed, that you are right. I have been weary of GNU's leftism, but I agree with the concept for non-real-time software applications. Perhaps that's the last remnants of my idealistic youth influencing my thoughts. Studying OpenBSD/FreeBSD has actually got me pondering on what sort of licensing I should really use. >I realize I'm quite biased here. I can assure you that it's not a casual choice either, for whatever that's worth. Remember, these lawyers are very definitely not our friends; they are much more likely to be used as tools and pawns, intended in their usage to subvert and destroy any open-source robowaifu movement. After all, just ask yourself -- who is paying these people anyway? Hard to argue against this. Past experience has shown men that this is indeed what happens. Must be prepared for it. >Also, would you care to spell out in further detail the terms 'strong license' and 'weaker license' if you would please? Of course. I think I started using "weak" after seeing in the CERN Open Hardware License (OHL) page. Apologies for the confusion XD Specifically CERN-OHL version 2 has three versions: -Permissive (CERN-OHL-P) -Weakly reciprocal (CERN-OHL-W) -Strongly reciprocal (CERN-OHL-S) CERN has a nice FAQ section on this: https://ohwr.org/project/cernohl/wikis/FAQ#q-what-are-all-these-suffixes Permissive is equivalent to BSD 3-Clause or Expat(MIT) where no changes need to be shared, only notices have to be retained. Relicensing is acceptable. This is likely the default license we should look into for any hardware (unless you know of equivalent licenses), as it explicitly covers production of products, not just distribution of the design files. Weakly reciprocal kinda feels like LGPL. Source licensed under CERN-OHL-W cannot be relicensed (similar to Apache 2.0), however if this source is used in a bigger design, the rest of the design can be licensed differently. Apache 2.0 actually has a clause on contribution (section 5), which by default retains Apache 2.0 (but could be explicitly adjusted by the contributor). If you want your hardware design to keep the same license, but still be used in any project, this is not a bad choice. Strongly reciprocal is equivalent to GPL (all changes to be published under same license). This license is similar to TAPR OHL v1.0 and GPLv3. In the context of licenses, I say "strong" when the license is "Copyleft" or similar to GPLv3. Only for projects that are fully open. So for us, either permissive or weakly reciprocal are viable options as they could be used in higher performance (however specifically permissive when code has to be combined together in a single binary). In further correspondence I'll try to use the terms "copyleft", "permissive", and "weakly reciprocal" to refer to the three categories set out by CERN-OHL. Oh, and for convenience, here are the links to the licenses I discussed so far (Chobitsu feel free to adjust as needed): GPLv3: https://www.gnu.org/licenses/gpl-3.0.en.html LGPLv3: https://www.gnu.org/licenses/licenses.html#LGPL BSD 3-Clause: https://opensource.org/licenses/BSD-3-Clause Expat (MIT): https://opensource.org/licenses/MIT Apache 2.0: https://www.apache.org/licenses/LICENSE-2.0.html CERN OHL Licenses: https://cern-ohl.web.cern.ch/home TAPR OHL License: https://tapr.org/the-tapr-open-hardware-license/
>>10935 Excellent response Anon, many thanks.
Open file (93.68 KB 1024x820 IMG_20210218_021948.jpg)
>>10927 >>10935 Thanks for all your input. I have to look deeper into this. Your link is again very fast about either the question if the wrapper is GPL, which isn't the issue. Or it's about linking within a binary, but not e.g. about importing some library in Python which interacts with some program written in C++. I will most likely use GPL licenced programs by others in my AI, so if this taints it, then it can't be avoided anyways. >>10931 >I also realize that -- particularly in a hard-realtime embedded environment of a robowaifu, that such modular and clearly-demarcated software systems is neither efficient, nor economical, nor even practical, by-and-large. I don't see myself ever working on anything that lives up to your standards, so you don't need to worry about it :^)
An anon has begun a valuable documentation project regarding a power & control network (>>11018). He would like to use an alternative license for it. >"From a legal stand point, this is under CC0 or public domain..." Can we please have a discussion on it's compatibility with our main BSD-3/Expat(MIT) licensing suggested for all our works here (on-board or off) anons? I'm unsure what CC0 means, but here's a listing from opensource.org. Maybe it goes by an alternative name also? https://opensource.org/licenses/alphabetical
>>11040 >CC0 As I suspected, it appears to be a Creative Commons license, the “No Rights Reserved” version. https://creativecommons.org/share-your-work/public-domain/cc0/ I wonder why opensource.org doesn't list it?
Open file (407.69 KB 940x836 asagohan.png)
>>11040 I think I'll use the MIT (Expat) license actually. Although I probably will have some work in the public domain as well (it's more suited for small pieces of code or self-contained written pieces etc.)

Report/Delete/Moderation Forms
Delete
Report

no cookies?