7 ms·

Is there any OSS implementation that is not AGPL?

by throwawayk8s 4y ago

ilyt 4y ago
Why would that matter? Apps using its api don't need to be AGPL
- tyingq 4y ago
  For some places, the in-house legal department makes it very difficult to use anything AGPL even if you assure them you're only using the api.
- throwawayk8s 4y ago
  We would like to self host and our legal team forbids us from using AGPL stuff.
  - remram 4y ago
    Sounds like a problem created entirely by your legal team, not software or licenses.
    - tomrod 4y ago
      Working with legal is advisable instead of ignoring it.
      - remram 4y ago
        The solution to "colleague got it wrong" is not "silently ignore them" and I never suggested that. In fact my suggestion is precisely that you "work with them" and have them review this specific case. "Don't use AGPL" is a good baseline rule if you don't have a legal team but does not apply in this case as I'm sure they'd advise if they reviewed it.
  - speedgoose 4y ago
    You should consider a replacement of your legal team.
- vlovich123 4y ago
  This doesn’t seem accurate. Isn’t AGPL viral across RPC boundaries requiring open sourcing not just the service but all supporting code for that service?
  - eropple 4y ago
    As far as I know, this isn't true. Some AGPL users claim that it is a requirement of the AGPL, but I am also unaware of any litigation that substantiates that reading of the license. Can you cite cases that have established this as fact?
    - mdaniel 4y ago
      I would suspect no one wants to invest the legal team or time to be the "trailblazer" court case to find out whether your theory or the common interpretation is correct. The "just ban AGPL" stance is by far the safer route since it's not like there are no sane replacements for AGPL stuff IANAL, and thus far my life is worse for any interaction with the legal system
      - eropple 4y ago
        It totally is safer, and I tend to agree with it in a business context. But the license itself doesn't seem to indicate that any kind of "RPC" is thus encumbered. When MongoDB was under the AGPL, your application wasn't under the AGPL if you connected to it and asked it to do queries.
  - deleted 4y ago
    [deleted]
  - freedomben 4y ago
    No it's not. From a practical standpoint, I'm not even sure how that could work. You would have to require all browsers to be open source AGPL in order to load a web page served by it. By way of analogy it seems the equivalent of requiring the mouse and keyboard firmware to be licensed the same as the operating system. A real life example is Instructure, which makes Canvas (which is agpl) but has other proprietary services that interact heavily with it. It's never been a problem 1: https://github.com/instructure/canvas-lms https://github.com/instructure/canvas-lms
- cpleppert 4y ago
  First of all, it isn't clear this is the case. But this entire comment thread on the AGPL misses the mark. It doesn't matter that the AGPL hasn't been tested in court or what fine grained distinctions you apply to the license or what the AGPL intends. No company in their right mind would risk using software licensed under the AGPL because the result of being wrong would be catastrophic. The legal advice to be skeptical of the AGPL is absolutely right. There is no conceivable reason to ever use AGPL software when you could simply license it under a commerical license or use a non-AGPL alternative. Generally when someone licenses something under the AGPL they totally understand this and that is their intention.
  - rakoo 4y ago
    Or, you could use AGPL software and license it under AGPL as well. Considering most money today is made in the hosting and servicing and not selling license, I don't see why you would bother caring about old fashioned ways.
    - mdaniel 4y ago
      You're right, Google should drop their policy and open source the whole thing, since it's their data and GCP services that are the crown jewels, right? https://opensource.google/documentation/reference/using/agpl-policy/ https://opensource.google/documentation/reference/using/agpl...
      - ilyt 4y ago
        They are talking about integrating it with rest of their apps in monorepo tho. Not running a completely separate service that you only talk via API It's kinda easy to miss that detail when you focus on bitching about license instead of the point.
      - rakoo 4y ago
        You're right, Google is a sane and healthy model of business to follow and surveillance capitalism, based explicitly on capturing data on users and selling it to third-parties for ads is something that benefits society as a whole. There are absolutely no models other than the one Google is running.
xyzzy_plugh 4y ago
Ceph Object Gateway is LGPLv2.1
habibur 4y ago
Seaweed. Apache license. https://github.com/seaweedfs/seaweedfs https://github.com/seaweedfs/seaweedfs
macintux 4y ago
I don’t think development is very active at all now that Basho is dead, but Riak CS is Apache licensed. https://github.com/basho/riak_cs https://github.com/basho/riak_cs
NexRebular 4y ago
Triton Manta is MPL https://github.com/TritonDataCenter/manta https://github.com/TritonDataCenter/manta
- mdaniel 4y ago
  Are you sure this offers the same S3 compatible API? It sure does look like it rolled its own API[1], which I guess is fine so long as you're entirely in the Triton ecosystem, but makes reusing existing software harder than necessary without that compatibility layer. And that's not even getting into this absolutely mess: https://github.com/TritonDataCenter/manta#repositories https://github.com/TritonDataCenter/manta#repositories it reminds me of the "Microservices" video come to life 1: https://github.com/TritonDataCenter/manta/blob/master/docs/user-guide/sdks.md https://github.com/TritonDataCenter/manta/blob/master/docs/u...

Is there any OSS implementation that is not AGPL?

ilyt 4y ago

Why would that matter? Apps using its api don't need to be AGPL

tyingq 4y ago
For some places, the in-house legal department makes it very difficult to use anything AGPL even if you assure them you're only using the api.
throwawayk8s 4y ago
We would like to self host and our legal team forbids us from using AGPL stuff.
- remram 4y ago
  Sounds like a problem created entirely by your legal team, not software or licenses.
  - tomrod 4y ago
    Working with legal is advisable instead of ignoring it.
    - remram 4y ago
      The solution to "colleague got it wrong" is not "silently ignore them" and I never suggested that. In fact my suggestion is precisely that you "work with them" and have them review this specific case. "Don't use AGPL" is a good baseline rule if you don't have a legal team but does not apply in this case as I'm sure they'd advise if they reviewed it.
- speedgoose 4y ago
  You should consider a replacement of your legal team.
vlovich123 4y ago
This doesn’t seem accurate. Isn’t AGPL viral across RPC boundaries requiring open sourcing not just the service but all supporting code for that service?
- eropple 4y ago
  As far as I know, this isn't true. Some AGPL users claim that it is a requirement of the AGPL, but I am also unaware of any litigation that substantiates that reading of the license. Can you cite cases that have established this as fact?
  - mdaniel 4y ago
    I would suspect no one wants to invest the legal team or time to be the "trailblazer" court case to find out whether your theory or the common interpretation is correct. The "just ban AGPL" stance is by far the safer route since it's not like there are no sane replacements for AGPL stuff IANAL, and thus far my life is worse for any interaction with the legal system
    - eropple 4y ago
      It totally is safer, and I tend to agree with it in a business context. But the license itself doesn't seem to indicate that any kind of "RPC" is thus encumbered. When MongoDB was under the AGPL, your application wasn't under the AGPL if you connected to it and asked it to do queries.
- deleted 4y ago
  [deleted]
- freedomben 4y ago
  No it's not. From a practical standpoint, I'm not even sure how that could work. You would have to require all browsers to be open source AGPL in order to load a web page served by it. By way of analogy it seems the equivalent of requiring the mouse and keyboard firmware to be licensed the same as the operating system. A real life example is Instructure, which makes Canvas (which is agpl) but has other proprietary services that interact heavily with it. It's never been a problem 1: https://github.com/instructure/canvas-lms https://github.com/instructure/canvas-lms
cpleppert 4y ago
First of all, it isn't clear this is the case. But this entire comment thread on the AGPL misses the mark. It doesn't matter that the AGPL hasn't been tested in court or what fine grained distinctions you apply to the license or what the AGPL intends. No company in their right mind would risk using software licensed under the AGPL because the result of being wrong would be catastrophic. The legal advice to be skeptical of the AGPL is absolutely right. There is no conceivable reason to ever use AGPL software when you could simply license it under a commerical license or use a non-AGPL alternative. Generally when someone licenses something under the AGPL they totally understand this and that is their intention.
- rakoo 4y ago
  Or, you could use AGPL software and license it under AGPL as well. Considering most money today is made in the hosting and servicing and not selling license, I don't see why you would bother caring about old fashioned ways.
  - mdaniel 4y ago
    You're right, Google should drop their policy and open source the whole thing, since it's their data and GCP services that are the crown jewels, right? https://opensource.google/documentation/reference/using/agpl-policy/ https://opensource.google/documentation/reference/using/agpl...
    - ilyt 4y ago
      They are talking about integrating it with rest of their apps in monorepo tho. Not running a completely separate service that you only talk via API It's kinda easy to miss that detail when you focus on bitching about license instead of the point.
    - rakoo 4y ago
      You're right, Google is a sane and healthy model of business to follow and surveillance capitalism, based explicitly on capturing data on users and selling it to third-parties for ads is something that benefits society as a whole. There are absolutely no models other than the one Google is running.

xyzzy_plugh 4y ago

Ceph Object Gateway is LGPLv2.1

habibur 4y ago

Seaweed. Apache license. https://github.com/seaweedfs/seaweedfs https://github.com/seaweedfs/seaweedfs

macintux 4y ago

I don’t think development is very active at all now that Basho is dead, but Riak CS is Apache licensed. https://github.com/basho/riak_cs https://github.com/basho/riak_cs

NexRebular 4y ago

Triton Manta is MPL https://github.com/TritonDataCenter/manta https://github.com/TritonDataCenter/manta

mdaniel 4y ago
Are you sure this offers the same S3 compatible API? It sure does look like it rolled its own API[1], which I guess is fine so long as you're entirely in the Triton ecosystem, but makes reusing existing software harder than necessary without that compatibility layer. And that's not even getting into this absolutely mess: https://github.com/TritonDataCenter/manta#repositories https://github.com/TritonDataCenter/manta#repositories it reminds me of the "Microservices" video come to life 1: https://github.com/TritonDataCenter/manta/blob/master/docs/user-guide/sdks.md https://github.com/TritonDataCenter/manta/blob/master/docs/u...