3 ms·

But for less stuff then if it was licensed under MIT.

by mnx 11y ago

Kototama 11y ago
Yes but the argument is unidirectional. AGPL answers different needs than more permissive licenses. Also it would be good to recognize the work done before shooting out "wrooooong license (for me)", specially when it still is licensed under a free software license.
- reitanqild 11y ago
  > Yes but the argument is unidirectional. I'd say yes. IMO there isn't a single thing you can do with a AGPL licensed piece of SW that you cannot do with a MIT licensed one, -the other way around, -quite a bit. > Also it would be good to recognize the work done before shooting out "wrooooong license (for me)" Sorry. Wasn't my intention but I can clearly see it being read that way. I just wanted to point it out as I personally don't like AGPL and wanted others to avoid the disappointment had.
  - jordigh 11y ago
    > IMO there isn't a single thing you can do with a AGPL licensed piece of SW that you cannot do with a MIT licensed one Sure there is. You can prevent others from imposing restrictions. If someone takes your non-copyleft software and uses it to build something that forbids people from knowing what's in it, how it works, or what it does with their data, then you are helpless to stop it.
    - reitanqild 11y ago
      And this is where our views differ: IMO nobody can impose restrictions to your MIT licensed code unless they can somehow threaten you and your users (think patents, law enforcement) in which case you have lost anyway. They can reuse your MIT code and impose restrictions on their modified code but we still have the free MIT code that is way free-er that AGPL and we also have an additional proprietary option. Edit: And if your worry is that they will use the code to create a commercial product with a slightly different file format etc this is a standards issue, not a open source issue. Furthermore, if there isn't liberally licensed code available they will just create their own broken/different version. Summarized: I am fairly convinced that for many companies the option to using BSD/GPL/LGPL/MIT code isn't using AGPL but rather using a commercial solution or write their own. Both this more or less guarantees you get no patches back to your open source project. AGPL is then just a way to make a statement.
      - jordigh 11y ago
        > IMO nobody can impose restrictions to your MIT licensed code Not to you, but to your users. If you don't care about your users' well-being, well... > use the code to create a commercial product I wish people who oppose the AGPL didn't see mistreating their customers as the only way of being commercial. There are several examples of commercial AGPL software. Yes, hiding the source code and forbidding them from copying the source code is mistreating them. If you are not doing anything wrong, then why are you hiding the source code? When software is naturally copyable, why are you denying them this natural right? > Both this more or less guarantees you get no patches back to your open source project There are also plenty of examples of copylefted projects getting even more patches than corresponding non-copylefted projects. There's a popular kernel called Linux that is copylefted and gets tons of industry-backed patches. People have been using that bugbear for as long as copyleft has existed. Mailpile got that threat when it switched to AGPL-only and so far its contributions haven't slowed down.
        reitanqild 11y ago
        > Not to you, but to your users. If you don't care about your users' well-being, well... They can still use my MIT licensed code which gives my user more rights than AGPL ever will. > Yes, hiding the source code and forbidding them from copying the source code is mistreating them. Now you are arguing against closed-source, not liberal open source licenses. > There's a popular kernel called Linux that is copylefted and gets tons of industry-backed patches. Note that you can use Linux on your server without announcing it to everyonce who acesses it. Also another reason for why patches are submitted are because industry hope their patches will be mainlined so there will be less maintenance. That said, GPL has worked well for the Linux kernel, possibly better than BSD. (I'm mostly arguin against AGPL.) > Mailpile got that threat when it switched to AGPL-only and so far its contributions haven't slowed down. Now that is interesting.
        jordigh 11y ago
        > Now you are arguing against closed-source, not liberal open source licenses. Non-copyleft licenses provide no protection against proprietary derivatives. If you have no objection to proprietary derivatives, then I think that's a weak stance to take. It means you don't care if your users can be given your software but without the rights that you intended them to have, because someone between you and your users can always take that right away. While your users might come back to you to get the same software with the same rights you intended them to have, they might not be aware of this, or they might not want your software alone, but together with whatever else was built on top of it, which they cannot get under your original permissive terms anymore.

But for less stuff then if it was licensed under MIT.

by mnx 11y ago

But for less stuff then if it was licensed under MIT.

Yes but the argument is unidirectional. AGPL answers different needs than more permissive licenses. Also it would be good to recognize the work done before shooting out "wrooooong license (for me)", specially when it still is licensed under a free software license.

reitanqild 11y ago
> Yes but the argument is unidirectional. I'd say yes. IMO there isn't a single thing you can do with a AGPL licensed piece of SW that you cannot do with a MIT licensed one, -the other way around, -quite a bit. > Also it would be good to recognize the work done before shooting out "wrooooong license (for me)" Sorry. Wasn't my intention but I can clearly see it being read that way. I just wanted to point it out as I personally don't like AGPL and wanted others to avoid the disappointment had.
- jordigh 11y ago
  > IMO there isn't a single thing you can do with a AGPL licensed piece of SW that you cannot do with a MIT licensed one Sure there is. You can prevent others from imposing restrictions. If someone takes your non-copyleft software and uses it to build something that forbids people from knowing what's in it, how it works, or what it does with their data, then you are helpless to stop it.
  - reitanqild 11y ago
    And this is where our views differ: IMO nobody can impose restrictions to your MIT licensed code unless they can somehow threaten you and your users (think patents, law enforcement) in which case you have lost anyway. They can reuse your MIT code and impose restrictions on their modified code but we still have the free MIT code that is way free-er that AGPL and we also have an additional proprietary option. Edit: And if your worry is that they will use the code to create a commercial product with a slightly different file format etc this is a standards issue, not a open source issue. Furthermore, if there isn't liberally licensed code available they will just create their own broken/different version. Summarized: I am fairly convinced that for many companies the option to using BSD/GPL/LGPL/MIT code isn't using AGPL but rather using a commercial solution or write their own. Both this more or less guarantees you get no patches back to your open source project. AGPL is then just a way to make a statement.
    - jordigh 11y ago
      > IMO nobody can impose restrictions to your MIT licensed code Not to you, but to your users. If you don't care about your users' well-being, well... > use the code to create a commercial product I wish people who oppose the AGPL didn't see mistreating their customers as the only way of being commercial. There are several examples of commercial AGPL software. Yes, hiding the source code and forbidding them from copying the source code is mistreating them. If you are not doing anything wrong, then why are you hiding the source code? When software is naturally copyable, why are you denying them this natural right? > Both this more or less guarantees you get no patches back to your open source project There are also plenty of examples of copylefted projects getting even more patches than corresponding non-copylefted projects. There's a popular kernel called Linux that is copylefted and gets tons of industry-backed patches. People have been using that bugbear for as long as copyleft has existed. Mailpile got that threat when it switched to AGPL-only and so far its contributions haven't slowed down.
      - reitanqild 11y ago
        > Not to you, but to your users. If you don't care about your users' well-being, well... They can still use my MIT licensed code which gives my user more rights than AGPL ever will. > Yes, hiding the source code and forbidding them from copying the source code is mistreating them. Now you are arguing against closed-source, not liberal open source licenses. > There's a popular kernel called Linux that is copylefted and gets tons of industry-backed patches. Note that you can use Linux on your server without announcing it to everyonce who acesses it. Also another reason for why patches are submitted are because industry hope their patches will be mainlined so there will be less maintenance. That said, GPL has worked well for the Linux kernel, possibly better than BSD. (I'm mostly arguin against AGPL.) > Mailpile got that threat when it switched to AGPL-only and so far its contributions haven't slowed down. Now that is interesting.
        jordigh 11y ago
        > Now you are arguing against closed-source, not liberal open source licenses. Non-copyleft licenses provide no protection against proprietary derivatives. If you have no objection to proprietary derivatives, then I think that's a weak stance to take. It means you don't care if your users can be given your software but without the rights that you intended them to have, because someone between you and your users can always take that right away. While your users might come back to you to get the same software with the same rights you intended them to have, they might not be aware of this, or they might not want your software alone, but together with whatever else was built on top of it, which they cannot get under your original permissive terms anymore.