CLAs create different issues than making (small) open source contributions
1–10 of 70 posts
Re: CLAs create different issues than making (small) open source contributions
#2I think the point was made, but worth emphasising from a different direction.
Different organisations have different goals when it comes to releasing code as Open Source.
Setting aside universities for the moment, companies (and especially startups) have (hopefully) a strategy which takes their product to commercialism and profitability.
Some projects go OSS purely for the marketing, attracting talent, unpaid labour and so on. But ultimately that means a pivot, and a CLA gives them more pivoting choices. They might cut out some contributers, but at the same time they serve the long game.
If you are wanting to contribute to a project, you, in turn, need to be clear what your goals are, and make sure they are aligned with the -long term- goals of the project owner.
Re: CLAs create different issues than making (small) open source contributions
#3I think the point was made, but worth emphasising from a different direction. Different organisations have different goals when it comes to releasing code as Open Source. Setting aside universities for the moment, companies (and especially startups) have (hopefully) a strategy which takes their product to commercialism and profitability. Some projects go OSS purely for the marketing, attracting talent, unpaid labour…
I don't think you can set aside universities when you talk about open source - they were the original drivers in this field, and continue to be heavily involved. The biggest difference is probably that most of the software written at a university is done by faculty and grad students and isn't work for hire, so for someone like me there's no reason to ever ask my employer to execute a CLA.
But the same problems arise in most other organizations - it's hard enough to get a legal department to sign essential things needed to keep a business running, never mind signing some random CLA for a project they haven't heard of.
Finally, your view seems oriented to pseudo-open source projects where someone slapped an open source license on code written at a single company and wants to keep control of that code within the company, rather than open projects spanning multiple organizations, run by the developers and architects of the code.
Re: CLAs create different issues than making (small) open source contributions
#4I've been turned off many times from contributing because projects had incomplete or inscrutable CLAs. Of course, the person in charge of asking for a CLA signature is usually not very knowledgeable about their own CLA, being a programmer and not a lawyer.
For example, I have been asked to sign CLAs that granted rights to "recipients" or "organizations" that they hadn't named, having simply adopted a template CLA without filling it in. Some placed specific requirements on me, like "notifying the Project Manager", without information on how to do that or who they were. cla-assistant.io even has the unbelievable default of stating that it's a "CLA for multiple repositories or organizations" without naming them. How can you agree to a contract without knowing where it applies?
In my experience it is rarely possible to legally contribute to a project that uses a CLA. You can ignore the legal issue with the assumption that none of it will come up anyway, but that's a weird way to approach contracts.
Re: CLAs create different issues than making (small) open source contributions
#5This is where I like the FSFE's Fiduciary License Agreement (https://fsfe.org/activities/fla/fla.en.html). It's more explicit about protecting free software. They solve a different problem to most CLAs, but align better with what I want my relationship with a project to be. For example KDE uses it (https://ev.kde.org/rules/fla/).
Re: CLAs create different issues than making (small) open source contributions
#6[deleted]
Re: CLAs create different issues than making (small) open source contributions
#7I've been turned off many times from contributing because projects had incomplete or inscrutable CLAs. Of course, the person in charge of asking for a CLA signature is usually not very knowledgeable about their own CLA, being a programmer and not a lawyer. For example, I have been asked to sign CLAs that granted rights to "recipients" or "organizations" that they hadn't named, having simply adopted a template CLA wit…
I factor CLAs into my determination of how difficult a project upstream is going to be to work with (incl. whether to remain downstream as a user, too—if I even am at that point) and/or how irrational its maintainers are. It doesn't inspire confidence, for example, when a project doesn't practice good hygiene with respect to keeping a tightly focused bugtracker (usually on the basis that it's too bureaucratic and they're lazy) but then turn around and ask you jump through a thousand unnecessary hoops that includes a CLA signoff just to fix a broken link in the README or code comments. And I have even less interest tacitly endorsing projects by people who get abusive or are obnoxiously stubborn about not being able to admit when they're wrong or reveal that they don't even understand their own CLA[1].
1. e.g., https://github.com/neovim/neovim/issues/3036>
Re: CLAs create different issues than making (small) open source contributions
#8I've been turned off many times from contributing because projects had incomplete or inscrutable CLAs. Of course, the person in charge of asking for a CLA signature is usually not very knowledgeable about their own CLA, being a programmer and not a lawyer. For example, I have been asked to sign CLAs that granted rights to "recipients" or "organizations" that they hadn't named, having simply adopted a template CLA wit…
I factor CLAs into my determination of how difficult a project upstream is going to be to work with (incl. whether to remain downstream as a user, too—if I even am at that point) and/or how irrational its maintainers are. It doesn't inspire confidence, for example, when a project doesn't practice good hygiene with respect to keeping a tightly focused bugtracker (usually on the basis that it's too bureaucratic and the…
[deleted]
Re: CLAs create different issues than making (small) open source contributions
#9I've been turned off many times from contributing because projects had incomplete or inscrutable CLAs. Of course, the person in charge of asking for a CLA signature is usually not very knowledgeable about their own CLA, being a programmer and not a lawyer. For example, I have been asked to sign CLAs that granted rights to "recipients" or "organizations" that they hadn't named, having simply adopted a template CLA wit…
I factor CLAs into my determination of how difficult a project upstream is going to be to work with (incl. whether to remain downstream as a user, too—if I even am at that point) and/or how irrational its maintainers are. It doesn't inspire confidence, for example, when a project doesn't practice good hygiene with respect to keeping a tightly focused bugtracker (usually on the basis that it's too bureaucratic and the…
As soon as I see a CLA I'm turned off even using a piece of FOSS software.
I get it's usually just the lawyers protecting the company just in case a contributor tries something dodgy in the future. Out of principle however, I resent the broad assignment of copyright and granting them the right to relicense.
Of course I expect most of these projects would never exercise that right, but the mere fact that they _could_ take my Free work and make it non-Free is very disturbing.
So I'm simply not going to use it. I'm not going to get invested, then find a problem that I could theoretically submit a patch for. Rather than think of all the users who would benefit from my change, I'll just see it as free work for a megacorp.
Re: CLAs create different issues than making (small) open source contributions
#10This is where I like the FSFE's Fiduciary License Agreement ( https://fsfe.org/activities/fla/fla.en.html ). It's more explicit about protecting free software. They solve a different problem to most CLAs, but align better with what I want my relationship with a project to be. For example KDE uses it ( https://ev.kde.org/rules/fla/ ).
How many weeks does this need?
I've lost many contributions over the insane FSF contributors license workflow. https://www.fsf.org/blogs/licensing/new-contributors-frequen...