3 ms·

Welp this is a bit of a chip in my near-term analysis of the situation[0], but I still think the future of F/OSS is AGPL. Also since I'm bit biased I think tha

Welp this is a bit of a chip in my near-term analysis of the situation[0], but I still think the future of F/OSS is AGPL. Also since I'm bit biased I think that there's an entire group of people who see this as a welcome to build their next google-beating startup attempt on AGPL since they know Google won't touch it (not that google was the undifferentiated-hoster type anyway). [0]: https://vadosware.io/post/the-future-of-free-and-open-source-is-agpl/ https://vadosware.io/post/the-future-of-free-and-open-source...

jupp0r 5y ago
Google will just buy a non-AGPL license from the license holders if they really want to use a particular piece of software.
- rapnie 5y ago
  I presume that then they may attempt to buy on a different license. And that you may say "No" to that.
  - Hamuko 5y ago
    I presume that if the software is non-trivial, Google's chequebook can convince most open-source maintainers.
    - rapnie 5y ago
      That is likely true. But I also know FOSS developers who outright rejected very large sums of money being offered for their work. From a combination of principles, values, not needing the money, or not willing to take responsibilities that come from such sale and/or restrictions of freedom that would mean. The "they just buy it" is the cynical assumption that everything always revolves around money. It often does, but not 100% of the time.
      - deleted 5y ago
        [deleted]
      - abricot 5y ago
        But now we are not talking about the sale of their work but simply licensing. J have not heard anyone rejecting large sums for licensing g code.
- hardwaresofton 5y ago
  And that's hopefully why it will be the future of F/OSS :) More money in the hands of F/OSS maintainers and teams will be the rising tide that gives us all even better ecosystems than we have now, I hope.
  - Thiez 5y ago
    So the future of F/OSS is all projects taking no outside contributions or requiring copyright assignment? How else will the core contributor(s) be able to sell a license to AGPL code they don't fully own?
    - hardwaresofton 5y ago
      Looks like it's time to update that article. It was primarily intended for self-hostable projects, and as others have discussed it's an issue for libraries! Also to more directly answer your question, the idea is that they sell a custom license to their own AGPL code -- if that code is mixed with code they don't own that is indeed a quandry! The royalty industry has a pretty well established model, so maybe we can use that. Again I want to point out that this is probably not reasonable for library authors (for many other reasons as well), I'm mostly thinking of people who are making software someone might want to rehost. Funny, there actually might be a business in here for managing the licensing and royalties for upstream projects in this future I'm envisioning ever comes true.
    - webmaven 5y ago
      > So the future of F/OSS is all projects taking no outside contributions or requiring copyright assignment? How else will the core contributor(s) be able to sell a license to AGPL code they don't fully own? You can do it without copyright assignment by, for example, contributors granting the maintainer a license to relicense their contributions.
- tgsovlerkhgsel 5y ago
  If the license holders are a definable and reachable entity. Once a project takes contributions without a CLA, there can be hundreds or thousands of authors, many of whom are unreachable.
- Seattle3503 5y ago
  That seems like a win for the maintainer.
gregmac 5y ago
I'm curious on your take of this for library code (as opposed to a full application like a web server or database). By count of projects alone, most of the OSS that I use is library code: parsers, REST client, compression, serialization, logging, IOC, unit tests, etc. I have absolutely zero interest in literally any aspect of the bureaucracy of paying for this, just for the sheer volume of projects. I'd be more likely to build - and release under an extremely permissive license - my own library for most of the above. I'm sure I'm not alone in that. I have no issue with A/GPL software (though employers sometimes do), but I very strongly prefer MIT/BSD for library code for everything I do (personal, OSS, and paid) because complying is easy and implications are minimal.
- hardwaresofton 5y ago
  IANAL, I'm a yak shaver by trade. That said, I think it's completely different for library code. Library code is conveyed to the user, whereas network access is not conveying a work. They didn't mention this, but even more abstractly, network access to the result of some computation is clearly not a sustainable thing to try to control either. > By count of projects alone, most of the OSS that I use is library code: parsers, REST client, compression, serialization, logging, IOC, unit tests, etc. I have absolutely zero interest in literally any aspect of the bureaucracy of paying for this, just for the sheer volume of projects. I'd be more likely to build - and release under an extremely permissive license - my own library for most of the above. I'm sure I'm not alone in that. > I have no issue with A/GPL software (though employers sometimes do), but I very strongly prefer MIT/BSD for library code for everything I do (personal, OSS, and paid) because complying is easy and implications are minimal. Yeah I think this is the fundamental breaking point -- AGPL is much more viral/complicated for conveyed works (as it was intended to be). Probably not a good idea in that use case. I should amend my post to note that AGPL is the future for self-hostable F/OSS, not necessarily library F/OSS. That said, I do think that it could be a great default license that encourages purchases for F/OSS though. If you're building F/OSS then the library is free for you. If you're not building F/OSS then pay for a separate license. If your goal is adoption (and the most users, arguably greatest good/utility) then AGPL stands in the way of that.
- adastra22 5y ago

jupp0r 5y ago

Google will just buy a non-AGPL license from the license holders if they really want to use a particular piece of software.

rapnie 5y ago
I presume that then they may attempt to buy on a different license. And that you may say "No" to that.
- Hamuko 5y ago
  I presume that if the software is non-trivial, Google's chequebook can convince most open-source maintainers.
  - rapnie 5y ago
    That is likely true. But I also know FOSS developers who outright rejected very large sums of money being offered for their work. From a combination of principles, values, not needing the money, or not willing to take responsibilities that come from such sale and/or restrictions of freedom that would mean. The "they just buy it" is the cynical assumption that everything always revolves around money. It often does, but not 100% of the time.
    - deleted 5y ago
      [deleted]
    - abricot 5y ago
      But now we are not talking about the sale of their work but simply licensing. J have not heard anyone rejecting large sums for licensing g code.
hardwaresofton 5y ago
And that's hopefully why it will be the future of F/OSS :) More money in the hands of F/OSS maintainers and teams will be the rising tide that gives us all even better ecosystems than we have now, I hope.
- Thiez 5y ago
  So the future of F/OSS is all projects taking no outside contributions or requiring copyright assignment? How else will the core contributor(s) be able to sell a license to AGPL code they don't fully own?
  - hardwaresofton 5y ago
    Looks like it's time to update that article. It was primarily intended for self-hostable projects, and as others have discussed it's an issue for libraries! Also to more directly answer your question, the idea is that they sell a custom license to their own AGPL code -- if that code is mixed with code they don't own that is indeed a quandry! The royalty industry has a pretty well established model, so maybe we can use that. Again I want to point out that this is probably not reasonable for library authors (for many other reasons as well), I'm mostly thinking of people who are making software someone might want to rehost. Funny, there actually might be a business in here for managing the licensing and royalties for upstream projects in this future I'm envisioning ever comes true.
  - webmaven 5y ago
    > So the future of F/OSS is all projects taking no outside contributions or requiring copyright assignment? How else will the core contributor(s) be able to sell a license to AGPL code they don't fully own? You can do it without copyright assignment by, for example, contributors granting the maintainer a license to relicense their contributions.
tgsovlerkhgsel 5y ago
If the license holders are a definable and reachable entity. Once a project takes contributions without a CLA, there can be hundreds or thousands of authors, many of whom are unreachable.
Seattle3503 5y ago
That seems like a win for the maintainer.

gregmac 5y ago

I'm curious on your take of this for library code (as opposed to a full application like a web server or database). By count of projects alone, most of the OSS that I use is library code: parsers, REST client, compression, serialization, logging, IOC, unit tests, etc. I have absolutely zero interest in literally any aspect of the bureaucracy of paying for this, just for the sheer volume of projects. I'd be more likely to build - and release under an extremely permissive license - my own library for most of the above. I'm sure I'm not alone in that. I have no issue with A/GPL software (though employers sometimes do), but I very strongly prefer MIT/BSD for library code for everything I do (personal, OSS, and paid) because complying is easy and implications are minimal.

hardwaresofton 5y ago
IANAL, I'm a yak shaver by trade. That said, I think it's completely different for library code. Library code is conveyed to the user, whereas network access is not conveying a work. They didn't mention this, but even more abstractly, network access to the result of some computation is clearly not a sustainable thing to try to control either. > By count of projects alone, most of the OSS that I use is library code: parsers, REST client, compression, serialization, logging, IOC, unit tests, etc. I have absolutely zero interest in literally any aspect of the bureaucracy of paying for this, just for the sheer volume of projects. I'd be more likely to build - and release under an extremely permissive license - my own library for most of the above. I'm sure I'm not alone in that. > I have no issue with A/GPL software (though employers sometimes do), but I very strongly prefer MIT/BSD for library code for everything I do (personal, OSS, and paid) because complying is easy and implications are minimal. Yeah I think this is the fundamental breaking point -- AGPL is much more viral/complicated for conveyed works (as it was intended to be). Probably not a good idea in that use case. I should amend my post to note that AGPL is the future for self-hostable F/OSS, not necessarily library F/OSS. That said, I do think that it could be a great default license that encourages purchases for F/OSS though. If you're building F/OSS then the library is free for you. If you're not building F/OSS then pay for a separate license. If your goal is adoption (and the most users, arguably greatest good/utility) then AGPL stands in the way of that.
adastra22 5y ago