3 ms·

thanks for saying the AGPL is nice; we think it strikes the right balance. but, i'm curious to understand your perspective here. do you mean to say that you'd

• SuperQue 6y ago
  The problem is CLAs. They are a much higher barrier to entry for a lot of contributors. No, they're not all the same, but they make it harder. Each CLA needs to be reviewed and approved by company lawyers. It's kinda like creating a brand new OSS license that way. To use a concrete example, the Google open source CLA is awful. At my previous job our lawyers refused to sign off the Google CLA. One of my engineers wrote a patch that we wanted to get upstream. Since, it would be generally useful. Basically, the patch could never be merged, because we had a legal stalemate between us and Google. I would highly recommend using https://developercertificate.org/ https://developercertificate.org/ instead. This is what we use for Prometheus. It's also used for GPL projects like Linux. It's simple, standard, and used widely.
  • __david__ 5y ago
    Does clause (d) allow the project to relicense its code? Because as far as I understand, that is the reason that GNU tends to have CLAs on their projects.
    • SuperQue 5y ago
      I'm no expert in these things, but here's my understanding. AFAIK, it's up to copyright assignment for re-licensing. For example, contributing to Prometheus assigns all copyright to "The Prometheus Authors". The DCO just attests that it's OK to do this. So, I don't think there's anything for or against re-licensing in DCO, it's just out of scope.
• shawnz 5y ago
  I think they are saying that they don't want to give the project owner permission to relicense their contributions to an incompatible license. Relicensing to a compatible license should be no problem.
• mqus 5y ago
  I as an individual on my free time would never sign any CLAs, but would be happy to contribute to Apache Licensed Projects. Why? Because CLAs make the sharing agreement asymmetrical. I want to provide my changes under exactly the same terms as you are providing your code. Additionally to the fact that CLAs are typically layed out in favor of the corporation and not of the contributor, they cause me to read that CLA, interact with it and most likely misinterpret it, because I'm a dev, not a/my lawyer. With common licenses I know what I'm getting and independent lawyers have created them, weighing the benefits of both sides. Of course, the last argument is not really applicable if you depend on widely-known CLAs like the Apache CLA (I use widely-known because I have heard of it, but I really have no clue what it entails and have never signed one). The issue of apache projects vs grafana is easy. I have never contributed to Apache projects and would hesitate to do so if I have to sign a CLA, but the issue is not as big because the License (AL2) of most of these projects already somewhat permits relicensing and AL2 is already a pretty weak license, because it is not infectious like the GPL family. But allowing relicensing on an AGPL project means that if I change anything on your code then I have to publish it. If you change anything you don't have to publish your changes (because you can relicense). This is not contributing on equal terms, so I'm out. Of course, one can also argue that you're doing much more work so the asymmetry is justified, but my work has not less value than yours and your benefit in this relationship already is determining where to go with the project. That said, I am not a lawyer and my understanding of licenses and CLAs is very limited and could also be wrong. I'm not even accounting for different legal environments/jurisdictions here.