@tuxether That's a good idea, one I heavily considered. I ultimately went with the current license for 2 reasons:
- The AGPL is unconventional for golang where everything is statically linked. So it would be a put-off for existing golang projects who would want to retrofit AP but cannot relicense easily.
- The AGPL'd code is all user-facing apps. Since this is a library, I can encourage new fediverse application creators to use AGPL to keep parity with the projects you listed.

@cj
1. By choosing the AGPL, existing open source golang projects can dual license, while proprietary applications will be forbidden. It's a win-win for open source and free software.
2. If you are well aware of the risks of not using the AGPL, then I would highly recommend the LGPLv3 (which has a linking exception for static linking) or the Apache 2.0 license. These protect the user from patent treachery and other such mishaps.

@tuxether More good points!
1: Still involves relicensing, which is the major barrier for existing projects (most projects couldn't do this)
2.1: LGPL would require non-stop(L)GPL licensed code to also do pre-link object releases (source is not sufficient). This is unconventional and a huge headache for potential adopters.
2.2: I can see the appeal of the patent grant, I have no patents so risk now is non-existent. But I should figure proof and add a patent grant for the future.

@tuxether A typo: I meant "future-proof"! Fat thumbing on my phone. :)

I am generally pro-GPL style of FOSS for end user applications. However, the weight of the Golang community is generally behind BSD, MIT, and Apache style licenses, and (L)GPL code is usually an instant death sentence for libraries, unfortunately.

@deadsuperhero Many thanks! Glad you found them helpful. I will also pass on the kudos to my wife who proofread the presentation (w/o understanding the topic) and got rid of a lot of my awkward sentences. Without her help it would've been a mess.

@cj

"However, as long as one major implementation can only handle one,this degree of flexibility cannot really be used. And by convention, it isn't.

"Of course, nothing stops someone from saying "screw that" and doing it anyway, breaking the Federation for others."

We intend to extend the ActivityStreams vocab quite a bit to add economic activities.
Do you have any tips for how to do that without breaking the Federation for others?

Here are our current notes:
https://board.net/p/AP-OCE

@bhaugen I agree with you that others should chime in and comment, critique, and correct the presentation.
I won't tag the folks here b/c I hate alphabet-soup mass-tagging. But in the interest of awareness, I'll try to respectfully do it in some one-on-one DMs.

@bhaugen On your current work on economic activities:

I'm happy to take some time to fully read your linked note (I only have the time to skim it right this second) and learn a little more about ValueFlows. But any feedback I'll have will be more skewed to be on a strategic level than tactical, as my knowledge of current fediverse conventions is second hand. Feedback from others to round out both the strategic and tactical levels will definitely be valuable; I hope you don't treat me as a one-stop shop! :)

@cj

Nope, I asked @mayel the same questions. But thanks your story, it was fascinating and scarey....

@cj

But I am always happy to talk to somebody who knows the diff betw strategy and tactics....