88

This one is something that were brought up a lot by developers including me who are very weary about corporations profiting off of our work for free and this basically put us off from contributing to open source in general.

We get a bunch of dialogues about this such as:

Developers like me: "Many of us who create are concerned about our work being exploited. The possibility of corporations profiting from our open-source contributions without giving back to the community disincentivizes us from participating in such endeavors."

Open-Source Advocates: "The AGPL exists to mitigate such concerns. It requires derivative works to also be open-source."

Developers like me: "While I appreciate the intention behind AGPL, there is a loophole - a 'condom code' if you will. Even though Linux Kernel prevents such strategies by refusing to merge these changes and that it's difficult for a singular corporation to force an adoption of a forked version of Linux Kernel, a corporation can fork our much smaller project however and introduce such legal bypass to the copyleft restrictions. This bypass can be justified by them under the guise of extending the software's capabilities with a plugin interface or an interprocess communication protocol layer, similar to how PostgreSQL allows User Defined Functions. However, I must caution that I'm not well-versed in the legal intricacies."

When bringing up on non-commercial clause for licensing

Open-Source Advocates: "Disallowing commercial use of your project contradicts the principles of open-source."

Developers like me: "Well, then perhaps we need a new term, something like 'Open Code Project'. We can create projects that encourage collaboration and openness while also restricting commercial exploitation."

So I created this post, because we do need to discuss on a path forward for Open Source in general knowing that corporation can shirk around this restriction and discourage developers like me from participating in open source or open code projects.

top 49 comments
sorted by: hot top controversial new old
[-] prof@beehaw.org 27 points 1 year ago

Contributing to open source projects is pretty much just altruism.

If we're talking about protection of people integrating open source code in their proprietary code we'll always have issues. It doesn't matter if we declare our projects under GPL, AGPL, LGPL, CC or whatever, unless they do shoddy work, we won't be able to know what code snippets, libraries or frameworks they're using when source code isn't disclosed.

People that want to be assholes will always be assholes. If you feel like giving back, contribute to an open source project. If you don't, don't. But making it about evil corporations is a bit meh. Even a company like Amazon is actively contributing to improving Java, offering the Amazon Corretto JDK for free. So the path forward may just be trying to be the change yourself, and making sure the company you're working for is also giving back somehow.

[-] Lionir@beehaw.org 18 points 1 year ago

I think the biggest con with this kind of license is that it also means neither you nor the collaborators can try to make a living out of it. Such a type of license forces entirely hobby work.

The cost of maintainership of the project and the fact that it may exclude people that don't have the privilege of being able to contribute in their free time are both things that concern me quite a bit when you remove all commercial usage.

[-] TheTrueLinuxDev@beehaw.org 6 points 1 year ago* (last edited 1 year ago)

From what I understood about the copyright law is that you could create a separate license apart from non-commercial license and you could still sell a commercial license (if all contributors agreed to it, CAA/CLA agreements been signed, or some other agreements in place.) A project can have multiple licenses. Please correct me if I'm wrong however.

[-] Lionir@beehaw.org 10 points 1 year ago

Yeah, that'd be the only way to do this but it also means the project can change the license at any time. As an outside developer, I would probably not want to rely on a project where it can go fully closed source potentially at any time.

It's also worth noting but if you have a non-commercial license, you will also be incompatible with any GPL license.

[-] TheTrueLinuxDev@beehaw.org 6 points 1 year ago

You raise a good point on that consideration.

[-] digdilem@feddit.uk 11 points 1 year ago

I agree, the parasitic nature of this relationship has been sharpened in the past week and made many of us think more critically of it.

My question is - what happens if several significant FOSS projects change their licence to "Sources must be publically available if repackaged" or even "Cannot be packaged for sale", specifically to prevent a non-freely available distro profiting from it.

Yes, that distro could fork the software at the point before the new licence is applied, but they they would be responsible for maintaining that fork going forwards, no? And that would take a lot of resources and need it to be called something else.

[-] TheTrueLinuxDev@beehaw.org 5 points 1 year ago

Absolutely, your understanding mirrors mine. The re-licensing process is a complex one, particularly in the context of FOSS projects with multiple contributors. It requires unanimous agreement from all contributors, unless a Contributor License Agreement (CLA) or Copyright Assignment Agreement is already in place, which can simplify the process.

As for the scenario where a distro continues to maintain a hard fork of the project from the point before re-licensing, it's certainly possible. However, as you pointed out, it would place a substantial burden on the distro in terms of resources. They would need to maintain and update the code independently, which might not be feasible or desirable.

In regards to the proposed license conditions, "Sources must be publicly available if repackaged" or "Cannot be packaged for sale", it's worth noting that the first one is already embodied in the principles of GPL/AGPL. The second proposal, however, raises more complex considerations. This approach would indeed help address the issue of commercial exploitation that I initially raised. But as you've mentioned, the challenge lies in navigating the re-licensing process.

If a FOSS project is already licensed under a different license, a re-license would require obtaining permissions from all contributors, which might prove to be a logistical challenge. Therefore, any change in the licensing model needs to be thought through carefully, taking into account not only the potential legal complexities but also the broader implications for the open-source community.

Disclaimer that I'm not a lawyer.

[-] jayrhacker@kbin.social 3 points 1 year ago

I recently came across this license, which addresses some of your concerns: https://commonsclause.com/

[-] TheTrueLinuxDev@beehaw.org 1 points 1 year ago

Thank you for posting this! It's very interesting on how it can be applied on top of existing open source licensing. I've got some reading to do!

[-] shebpamm@lemmy.ml 2 points 1 year ago

Reminds me of what happened with elasticsearch and amazon.

[-] janus2@lemmy.dbzer0.com 11 points 1 year ago* (last edited 1 year ago)

Isn't the ultimate issue enforceability? For a dev to be awarded some of the profit made off an open source project:

  1. A whistleblower would have to discover, gather, and publish evidence that the software was being used to generate profit
  2. The dev would have to win a court case against the company

It would be fuckin rad if that happened and a dev got a huge payout and a legal precedent was set. But it'd be more rad if we didn't live in a society where this was an issue in the first place :[

[-] goddard_guryon@sopuli.xyz 10 points 1 year ago

Just to add to the topic, the 'condom code' point you bring up is actually well-established in the business - the so-called 'Embrace, Extend, Extinguish' technique.

[-] TheTrueLinuxDev@beehaw.org 3 points 1 year ago

And it sucks that it such a massive discouragement from a lot of developers who shared similar concerns as I have about this.

[-] boris@news.cosocial.ca 9 points 1 year ago

There are a number of licenses that do this. And yes, many of them are not OSI approved and people will say mean things about not using the word open source. Which you should ignore and instead perhaps say fair source instead if you care.

A couple to look at:

Big Time License

a public LICENSE that makes software free for noncommercial and small-business use, with a guarantee that fair, reasonable, and nondiscriminatory paid-license terms will be available for everyone else

Prosperity License

Prosperity is a public LICENSE for software that makes work free for noncommercial use, with a built-in free trial for commercial users.

I also recommend going through the back log of posts by Kyle Mitchell, an engineer - lawyer who has authored a number of great software licenses, including the two I listed.

[-] density@kbin.social 6 points 1 year ago

You want an option analogous to NC in Creative Commons:

Only noncommercial uses of the work are permitted

https://creativecommons.org/about/cclicenses/

[-] lengsel@latte.isnot.coffee 6 points 1 year ago

It's a broder societal cultural problem. No license can ever fix it. Companies and corporatons are made up of people, and if life has only taught them to wreck everybody they can, they will do their work with a mentality of exploiting any chance they to make sure only they succeed.

Any kind of long term fix to change corporations will take generations, not a legal standard.

There was a time when a verbal agreement and a handshake was an unbreakable commitment because people shared a common set of principals and personal values that bonded people together. It took generatios to destroy that sense of honour, it will take generations to get back to that. People are delusional if they think corporate exploitation can be fixed through courts, the law, or politics, only culture.

[-] rimu@kbin.social 6 points 1 year ago

You don't need to read much history to find plenty of bad things done by non-commercial entities, e.g. governments. Or churches.

It's not commerce that is the problem, it is oppression. Use of my code for oppressive purposes is the thing I want to avoid.

[-] nfriedly@kbin.social 6 points 1 year ago

I've worked at more than one job where I was told it was OK to use MIT, or Apacje-2.0 licensed things, but to not touch any GPL or AGPL software.

So, even though there wasn't any non-commercial clause in the license, it's copyleft nature led to that effect at those businesses.

In general, I like the balance that the GPL & AGPL strike - commercial use is allowed, but the company has to give back. The "condom code" thing that you mentioned is certainly less than ideal. I would prefer that businesses open up their full codebase. But, I think the more likely scenario is that they just don't use any open source at all (or they use it and violate the license!) I'd prefer condom code over either of those possibilities.

[-] agrammatic@feddit.de 6 points 1 year ago

I basically take the position "you need a different, non-confusing term". Open Code is not such a term.

My view is shaped from the cultural realm more so than the software side, but I think the concern at the centre of it is transferable: it becomes extremely messy to capture the desired acceptable uses in the legal wording of an enforceable license. The outcome is that every use will have to be individually authorised.

I was helping run and occasionally held the editor role of a leftist magazine which we decided to make Free Culture under CC-BY-SA. Content using the Non Commercial clause gave us such headache, while even though we did not charge for the magazine nor we ran adverts, we accepted and strongly encouraged donations from our readers. That money went to pay off the printing costs (the NC clause already has a problem with that, but we assumed that would still be defensible), but the rest was also invested in other endeavours like public events, or eventually helping fund a community centre.

At that point, it didn't matter if creators with NC works released them under a supposedly free license. Our -in our opinion- non-for-profit use was still so tainted with money changing hands, that we still needed to seek their consent and get a written permission on top of the original license. At the end of the day, it was the same as working with All Rights Reserved works, where we get a special license from a sympathetic creator. The NC clause solved nothing for us.

That part is, I believe, the same with software licenses. We will end up having to get 1:1 license agreements for so many things because the new anti-commercial licenses will not be able to predict all the scenarios which are "false positives" for the anti-capitalist software developer (as in, some desirable re-uses will be blocked by the license, and individual licensing agreements will be needed often).

My focus would be to fix the loopholes that go counter to the copyleft spirit in AGPL, if such loopholes are identified, and perhaps get a more reliable organisation handle the AGPL definition in the future.

[-] federico3@lemmy.ml 6 points 1 year ago

Software licenses cannot solve every problem and AGPL is still the best option.

There are many larger problems related to FOSS including freeloading, right of repair, surveillance, lock-in... and they require social solutions rather than new licenses.

[-] syrinx20xx@kbin.social 6 points 1 year ago

@TheTrueLinuxDev - If your goal is indeed non-commercial usage, then what you need is a clear new license with a clear new name: "Non-Commercial Source License" (NCSL), or possibly "Public Domain Source License" (PDSL).

[-] boothin@kbin.social 5 points 1 year ago

MongoDB has a modified version of the AGPL that they call Server Side Public License that might interest you. Specifically the change in section 13:

“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.

By my reading, it closes that loophole you mention by specifically calling out interfaces and APIs as also requiring the source to be available. At the top of the page I linked there is also a PDF showing the removals and additions they made to the AGPL to end up with their SSPL.

[-] TheTrueLinuxDev@beehaw.org 7 points 1 year ago

That a pretty interesting license, I distinctly remember that there were an argument on the internet over that license. So I took the time to review what happened, there were few criticisms for it:

Conflict over "Open Source" Definition - Open source license must allow the software to be freely used, modified, and shared. The SSPL adds additional restrictions, particularly the requirement to open source not just the software itself but also the software used to offer the program as a service.

Restricts Freedom to Use the Software - It requires that anyone who makes the software available as a service must release the source code for their entire stack.

But none the less, this license is an interesting one and an inspiration could be drawn from it to not go to that extreme stipulated by SSPL, but to have some lines drawn to address some of the concerns around AGPL loopholes.

[-] commandar@kbin.social 4 points 1 year ago

Restricts Freedom to Use the Software

I've always found this particular one somewhat frustrating. It's essentially the intolerance paradox repackaged into a software licensing analog:

"You are restricting the freedom of users by taking away their ability to close the code and restrict the freedom of other users!"

It's always read very "I got mine" to me.

That said, while I lean copyleft, I also don't find just barring commercial use entirely interesting. The goal is to ensure source code remains available to users; I think there are better ways of addressing that than trying to delineate and exclude commercial use.

[-] TheTrueLinuxDev@beehaw.org 2 points 1 year ago

That one of the reason why I brought up this thread to bring up discussion on some of the other ways we could address this while retaining commercial use.

My interpretation of non-commercial licensing is that it would allows the code to remain open, it just that it may mandates companies to purchase commercial license if they wish to peruse such project commercially. There are some projects that practiced dual licensing schemes.

[-] vaguerant@kbin.social 3 points 1 year ago

This isn't a hill I'm willing to die on at all, but it does mildly annoy me that The Open Source Definition is used by proponents to mean the same thing as "open-source". For anyone not familiar, The Open Source Definition is a document used to determine whether code should be certified by the Open Source Initiate as "OSI Certified". Proponents argue that anything which does not meet the OSI's definition is not open-source, while I think there's room in the language and the mind for disagreement on whether "open-source" and "eligible for OSI certification" are synonyms.

The OSI was originally founded with the goal of registering a trademark for "Open Source", but this was unsuccessful as the term is too broad and descriptive. Failing that, the OSI decided to instead register the trademark "OSI Certified", which can be applied to works which meet their Open Source Definition. Ultimately, what this means is that nobody owns the phrase "open-source" and it's an organic part of language which is not strictly defined by the specific terms of any certifying documents.

Over the years, there have been plenty of non-commercially licensed software with source available for use: a popular example is video, computer and arcade game emulators. The MAME emulator was for years released under its own non-commercial copyleft license before eventually being relicensed under BSD (which meets OSI's Open Source Definition), and popular SNES and Mega Drive/Genesis emulators Snes9x and Genesis Plus GX both continue to be released under similarly "open but non-commercial" licenses.

I'll happily agree that none of those are eligible to bear the "OSI Certified" trademark and that they don't meet OSI's Open Source Definition. But when people start saying they're "not open-source" it rubs me the wrong way, because we're just talking, not trying to achieve trademark certification. Not to mention that the whole nature of software licensing is to note what restrictions there are on the use of the code, e.g. most open-source, copyleft licenses deny you the right to use their code without attribution. However, we basically all agree that that's fine and you can still call a license open-source if it includes that restriction. It's a shades of gray situation that people are treating as black and white just because a definition exists which they can refer back to, with the assumption that all people must subscribe to those specific terms.

There's entirely valid counter-arguments, of course. It's useful to have strict definitions of nebulous concepts like open-source because it could cause confusion, and you have to draw the line somewhere or else the term becomes completely meaningless. e.g. You risk people referring to things like source code leaks as "open-source". There are frequently cases of people ignoring non-commercial license terms and selling those softwares (Snes9x and Genesis Plus GX are often bundled with commercial retro emulation hardware), which you could argue stems from confusion about whether or not commercial use is allowed. But the same devices often violate the licenses of OSD-compliant software as well, so it seems more likely they just don't care about open-source software licensing terms.

So anyway, Genesis Plus GX is open-source but I'm not willing to fight you about it.

[-] boothin@kbin.social 2 points 1 year ago

Yeah, I think it falls squarely into your thing about a new term from open source as its not recognized as being open source by the OSI and probably won't be due to it being too restrictive, but the restrictions close the loopholes, forcing the software to be more free at the same time so it's kind of in a weird spot

[-] thejevans@lemmy.ml 5 points 1 year ago

It hasn't been tested in court yet in the US as far as I know, but non-commercial licenses can potentially be more restrictive than you intend. As such, I don't contribute on projects with non-commercial licenses and I know others who do the same.

That said, I understand the frustration of big companies using your code for something big and you not getting a share of the profits. That frustration though, either as a frustration of capitalists benefiting from your work or from you not getting profit you feel you may deserve, seems like a nothing-burger to me. If you weren't planning on selling licenses to your code before-hand and them using it doesn't affect the maintenance burden that you have, then what is the problem? It functionally changes nothing concerning the time and effort you were planning to put in.

The power of open-source licenses is in how they allow for quick and painless sharing of software for the collective benefit of others. There are tons of ways to get paid while using open-source licenses. Non-commercial licenses are unnecessary bloat that could gum up the works.

Correct me if I'm mistaken. What I read from your post sounds to me like you think that we should accept that a company will inject a revenue stream into the process that we all were working on as an open source project. We weren't expecting to get paid, so why not allow the company to get paid, regardless of the downstream impacts for other projects that once relied on the project being completely free and open. Do I understand that properly? I don't want to misrepresent your intent. I feel like I must be misunderstanding something.

[-] thejevans@lemmy.ml 0 points 1 year ago

I'm a socialist. I believe at a societal level that it's messed up that companies can turn exploited labor into profit for capitalists instead of distributing it fairly among workers.

On an individual level or individual project level, how would a company using your code for profit on their own project affect the availability or accessibility of your original version?

I'm happy to be proven wrong here, but my understanding is that FOSS is an important tool to combat the consolidation of technology into the hands of a few capitalists, and it generally relies on the free altruistic labor of people for the good of the commons. All else being equal, it would be a much better world if that work was always paid for, but I don't think we can have that in a capitalist society without sacrificing the best parts of FOSS.

I think we may be talking about two different things with regards to corporate control. I'm saying that, in the case with Redhat specifically, that their injection of a fee to access the source code now no longer makes the code freely available to downstream repositories. If they comically charged a billion dollars to access the source code (with a GPL) it would practically become closed source, so I'm curious why any entity can charge any amount to access open source software. And if it's totally legal with this type of license, doesn't that mean that we should be avoiding GPL at all costs?

[-] thejevans@lemmy.ml 2 points 1 year ago

Yes, we are talking about different things. I don't know enough copyright law to know what to think about the RHEL situation yet, i.e. source available vs. open source. I've been talking about a theoretical open source project that you control and a corporation downstream using it for profit.

[-] buckykat@lemmy.fmhy.ml 5 points 1 year ago

To ensure software freedom you must first destroy capitalism

[-] conciselyverbose@kbin.social 5 points 1 year ago

I kind of want GPL, but with one extra clause that says that violating the terms of the GPL permanently and irrevocably terminates all right to touch anything else under the same license, including your own code.

[-] RandoCalrandian@kbin.social 3 points 1 year ago

Fat chance. We can’t get the existing terms of GPL to be enforced

Re: red hat restricting redistribution of GPLv3’d code

[-] tiny@midwest.social 4 points 1 year ago

There are already licenses like this. Namely the sspl and the bsl. Id argue they drive away more contribution than they protect devs. Especially sspl because it's not clear if I have to open my entire automation repo if I give a 3rd part contractor access to a web app. Also they are not open source since they restrict who can use it

[-] MJBrune@beehaw.org 4 points 1 year ago* (last edited 1 year ago)

Simply put, for works you want to prevent from being commercialized by other companies. Don't open-source it. Keep it closed source. If you feel like it, put an email address out there and say something like "if you want access to the source, let's talk." It requires you to vet everyone who has access but if you are wanting to be that guarded with your code then that's what you need to do.

That said you could just BSD/MIT license your code. If your project is small it's unlikely to even be noticed. In the end, any license you create that offers the source code without applications means it's open for any corporation to just take. Regardless of the code license. The fact is that you are a small-time developer and don't have the power of lawyers to counter them. So either open your code for everyone, vet each entity you open the code for, or don't introduce the headache of dealing with any of this and keep it closed. Tell yourself you will open the source later on after you are done with it.

Realistically, these are your options. There are plenty of creative commons or such licenses that exist to exclude commercial works but again, lawyers cost money. If you aren't willing to fight the battle you might as well CC0 the code because that's essentially what it is.

[-] TheTrueLinuxDev@beehaw.org 2 points 1 year ago

You sum up what I thought about as well, yep. There are compromises to each license and obviously the loophole that is presented for each one. One of the idea I was exploring is licensing my GUI Toolkit (alternative to GTK and QT) something similar to Community License in Visual Studio (it allows commercial use for personal/small business and if organization is larger than that, then it would have to purchase a separate license.)

[-] MJBrune@beehaw.org 1 points 1 year ago

Check out Epic's Unreal Engine License. Essentially after a certain amount of income they require revenue percentages from sales of the product. You could likely do something except as a flat fee rather than a percentage of sales. Again, though, enforcement takes money though. Is your GUI toolkit so revolutionary that people will even use it? It's more likely to get more people using it if it's open source but of course, it means you can't really monetize it to commercial projects.

[-] TheTrueLinuxDev@beehaw.org 0 points 1 year ago* (last edited 1 year ago)

I don't think it's that revolutionary, but there are some things that doesn't exist in current GUI Toolkit worlds.

The GUI Toolkit I wrote utilize few things:

  1. It runs on Vulkan and the pipeline use custom developed 2D rendering context, not 3D so there is a significant boost in performance and reduction in computation requirements on both GPU and CPU. Vulkan allows GUI to work on just about any devices made in the last decade and can fallback on CPU using Swiftshader.
  2. I established FFI-JSON to simplify binding for any programming languages to bind to my GUI Toolkit as well as extending the GUI Toolkit itself.
  3. Designed for Buffer-based controls - If you want to load up a 2GB text file into a textbox, it offers a way that it would work without freezing up the program.
  4. Accessibility protocol in IPC - Similar to DBus, but documentations are provided to simplify the process of utilizing such protocol and it's focusing on cross-platform conventions where Dbus might not be available.
  5. Library itself is Cross-platform and written in C Language, enabling the larger cross-section of compatibility
  6. The project is built for IR linkage purposes hence why the code should be open source, because the code is already open by IR anyway. By offering IR linkage by default rather than Object files or dynamically linked library, IR allows everyone to gain immense performance boost through compiler's features of auto-vectorization, dynamic dispatch converting to static dispatch when possible, internalization pass and more aggressive dead code eliminations. It's not unusual to see a 80% reduction in code size through this process and see as much as 10x performance improvement compared to dynamically linked libraries.
  7. Conventions for stylizing/theming the GUI through CSS (the goal is to offer a permanent theming capability in GUI even though it can be a challenge to maintain.)

That on top of my head, I wanted to have a GUI that focuses on making it easier to extend while keeping it conventional for those familiar with Windows Forms on Microsoft Windows and eventually WPF if time allows.

That the gist of why I wrote my GUI Toolkit and I have spend 4 years working on it, it's reaching the point that it could be ready for prime time basically.

The licenses you brought up is interesting and it could work too.

[-] MJBrune@beehaw.org 0 points 1 year ago

Okay, now I am interested in learning more about this GUI toolkit even though I am a game developer, not an app developer. Got a website or such?

[-] TheTrueLinuxDev@beehaw.org 2 points 1 year ago

Currently early atm, but generally, I got the backend code sorted out where we have cross-platform windowing context, vulkan code, accessibility protocol, and so forth. The challenges are the front end GUI, making it looks pretty, it's still have a way to go.

And of course the documentation which is still WIP. I wrote other docs sometime like this for C language development community which I have put off for a while since I worked on few projects:

  1. Finish making deliverable for AI Framework to replace Pytorch/Tensorflow that uses IREE Compiler for my client. (IREE Compiler basically takes in your MLIR code and compile that to either SPIR-V shader code, CUDA code, ROCm, or anything else really rather than just mainly CUDA on Pytorch/Tensorflow.) I should have this done by tomorrow, it just making a web for my client that is 90% done and I just have to plug my AI into it.
  2. Work on Melosynthos which is basically a Compiler Generator, it's about 60% done and can help a lot on building unit tests for GUI Toolkit.
  3. Finish up GUI Toolkit and try to make GUI that takes some inspirations from this
  4. Finish up documentations for that GUI Toolkit
  5. Build a web to demonstrates GUI Toolkit and let people go nut with it.

The best part is... I solo-develop all of it... facedesk

[-] tom42@beehaw.org 3 points 1 year ago

Historically the GPL seems to be not cermercial in the sense of taking care for developers rights. The GPL is also connected to the term Open Source. Because it was too restricted for some cases a derivation was made witj the LGPL with which it is posdible to use GPL licenced libraries easier in combination with other more restricted or more opened licenses.

For some looking for Free Software all this was too restricted and the libre BSD license and all its derivations were made.

There are several licenses which forbid commercial use. But where does this work? When I want to use a piece of software while working on a profitable project it is commercial use. It may be on purpose to restrict this but sometimes it is not meant to be not free.

[-] HaleyHalcyon@kbin.social 2 points 1 year ago

I’ve heard of the term “copyleft”, which allows everyone EXCEPT corporations to use a certain work.

[-] TheTrueLinuxDev@beehaw.org 19 points 1 year ago

Well corporations can use the given work too, it just that they also have to disclose their derived work of the given code and have it licensed under GPL or AGPL as well. That the general idea of copyleft.

[-] unicorn@mander.xyz 3 points 1 year ago

The meaning of copyleft is just that those who use the license have to typically also use the same or a similar license. There is no restriction to who can use it, just to the terms under which they can use it and have to license it.

GPLv3 for example does not allow derivative works to be closed source, while MIT does. In practice this makes some companies hesitant to use GPL-licensed works, but they can, and many do, they just have to abide by its rules. :)

[-] jcolag@vlemmy.net 2 points 1 year ago

While I don't want to even pretend to tell you how to make your decisions, you actually provide your own argument for why non-commercial licenses fail: Just like you can cordon off AGPL code and not let it touch your main project, big corporations are more than happy to juggle accounting tricks to make a certain piece of a project look "non-commercial," if it'll make them money.

In my opinion, it'd be better to force them (by the terms of the license) to contribute changes back upstream, so that if you disapprove of their use, you have the ability to publicly shame them as it happens.

[-] InvisibleShade@kbin.social 0 points 1 year ago

Do you mind explaining the loophole to the AGPL a little more? I didn't quite understand that part.

[-] RandoCalrandian@kbin.social 1 points 1 year ago* (last edited 1 year ago)

He’s saying they add a plug-in system to add additional functionality, but the plugins don’t have to be open source and can be DRM’d to hell

load more comments
view more: next ›
this post was submitted on 26 Jun 2023
88 points (100.0% liked)

Free and Open Source Software

17848 readers
5 users here now

If it's free and open source and it's also software, it can be discussed here. Subcommunity of Technology.


This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 2 years ago
MODERATORS