I agree with this. Go needs a pdf library that is apache, mit or bsd licensed. For a small commercial service where we don't want to share our own source code, AGPL prohibits use and the commercial license is probably not going to be affordable to a low-margin internet startup. It's weird that in the pdf library space, it's common for an AGPL to be used (e.g. xpdf, itext), even though it's a library and we'd be required to share our own source code to use them. Also, Go uses static linking, which is specifically mentioned in the LGPL, so a go program using a lgpl library should in theory distribute its source as well.
[1] https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic Kristian On Tuesday, 19 July 2016 10:38:19 UTC+10, Eric Johnson wrote: > > > On Monday, July 18, 2016 at 4:45:37 AM UTC-7, rog wrote: >> >> On 16 July 2016 at 16:33, Daniel Theophanes <kard...@gmail.com> wrote: >> > I would also note that AGPL is probably unusable in most Go programs >> > (statically linked and all). -Daniel >> >> Why so? You just need to make your program open source, which shouldn't >> be too onerous a requirement I'd've thought. >> > > IANAL, but the viral nature of the AGPL might be an issue. > > Just to be clear, I understand your business proposition, and if it works > for you to use the AGPL, then you should do that. I'm just addressing the > question of how the use of the license plays out. > > Any project that builds upon your project is effectively also under the > AGPL, whether or not they want to provide their extensions under a > different open source license. In fact, allowing downstream developers to > use a different license than AGPL is just asking for trouble. > > The exceptions you've provided for open source use probably make perfect > sense to a lawyer, but to a developer downstream of this, it is one more > thing that they have to keep track of. Imagine a poor user who does a "go > get" of a library built upon your library, and they vendor it into their > source tree. They might not notice that the go get operation pulled down a > dependency that is licensed differently from the dependency that they were > fetching. If you're lucky, the dependent library will include a license > file that explicitly declares the dependency. If your unlucky, developers > who are not lawyers won't notice the constraint, and it will end up causing > people headache, just because it deviates from the community norm of a BSD > or Apache style license. > > I don't know that there's an easy way to solve this, because the chosen > license fits a known open source business model. > > Eric. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
