7 ms·

CLAs create different issues than making (small) open source contributions

60 points by pabs3 3y ago

bruce511 3y ago
I 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.
- pjdesno 3y ago
  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.
  - tmpX7dMeXU 3y ago
    This feels like…one degree away from a no true Scotsman argument.
    - bkor 3y ago
      Why? Getting someone so sign off on a CLA is a huge burden. There are loads of companies that have huge software development teams but the company is NOT an IT company. Legal isn't setup to figure out a CLA. At least that's in my experience. It's significantly easier to not contribute back than spend ages trying to involve legal. Sort of like a barrier to entry, though maybe called a barrier to contribute.
  - bruce511 3y ago
    Yeah, I would argue the projects requiring a CLA are exactly as you described - companies that want to keep specific future options on the table. OSS covers a wide spectrum of projects, from the Linux Kernel at the one end, to Frank's recent half-assed attempt at a CSS editor. Clearly no statement is going to cover everything. The set of projects that require a CLA, and the set of pseudo OSS projects has a high degree of overlap.
remram 3y ago
I'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.
- cxr 3y ago
  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 https://github.com/neovim/neovim/issues/3036>
  - deleted 3y ago
    [deleted]
  - williamvds 3y ago
    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.
milliams 3y ago
This is where I like the FSFE's Fiduciary License Agreement (https://fsfe.org/activities/fla/fla.en.html 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/ https://ev.kde.org/rules/fla/).
- rurban 3y ago
  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-frequently-asked-questions-faq-guide https://www.fsf.org/blogs/licensing/new-contributors-frequen...
  - aragilar 3y ago
    FSF != FSFE.
    - rurban 3y ago
      I do hope very much. FSFE is the evil empire, the FSF the good one
      - remram 3y ago
        It seems like you might have meant the opposite, based on your previous remark? Did you?
deleted 3y ago
[deleted]
amtamt 3y ago
Can there be somewhat standardized CLAs, along the lines of Apache/ MIT... licenses?
- bkor 3y ago
  I'm aware of the following: https://harmonyagreements.org/ https://harmonyagreements.org/ Still, CLAs are a barrier on their own already. Standardizing them doesn't help. Plus as another commenter mentioned: sometimes a standard CLA is used but then various bits aren't filled in.
  - hgs3 3y ago
    Standardizing CLA's helps the same way standardizing software licenses helps prevent license proliferation [1]. Code hosting websites, like GitHub, should provide a mechanism for registered users to electronically sign a CLA from their web interface. No hassle, no unfilled bits, and you've got a 3rd party (e.g. GitHub) notarizing the contract. [1] https://en.wikipedia.org/wiki/License_proliferation https://en.wikipedia.org/wiki/License_proliferation
    - cxr 3y ago
      The solution to CLA proliferation is not the proliferation of CLA use, which is what your suggestion involves. If you want to solve CLA proliferation, it's as easy as not going out of your way to add a CLA to your project followed by insisting that people sign it. Let the strength of the license (and your faith in the choice of license) stand on its own.
bmitc 3y ago
How is a CLA any different of a legal agreement than agreeing to a license? The CLAs I have seen basically boil down to the project maintainers maintaining ownership of the code, ability to adjust the license if desired, and protect them from people contributing code that the contributor doesn't have the rights for. I have seen projects suffer from single contributors stubbornly refusing to budge on relicensing, even if the relicense would benefit the project.
- A1kmm 3y ago
  If I contribute to an AGPL project and license my changes back to you under AGPL, that means you can't one day decide to start selling my changes together with a closed-source module; the copyleft works to protect me against you deciding to take my changes closed-source, not just to protect the original maintainer from that. If I contribute to an AGPL project and sign a CLA that assigns copyright to you, you might announce tomorrow that you are going to run off with my contribution and start only releasing new versions under a non-FOSS licence. This fear applies particularly if you are a for-profit company who might one day lose your desire to do FOSS. This exact thing, in fact (other than the AGPL part anyway) happened recently with just about every Hashicorp project - so it is not just some hypothetical fear. I would not contribute (unless I was being paid) to someone else's project unless there was no CLA (inbound = outbound licensing), or they were a not-for-profit with appropriate constitutional limitations on profit-seeking behaviour.
  - pydry 3y ago
    >If I contribute to an AGPL project and sign a CLA that assigns copyright to you, you might announce tomorrow that you are going to run off with my contribution and start only releasing new versions under a non-FOSS licence. That is generally the point of a CLA. If that bothers you you're supposed to not contribute and not sign. The up side is that that revenue model might mean that they can pay people to do that work instead of relying upon drive by pull requests and maintainers dedicating their time for free. Back in the early days of open source I saw a lot of people get mad at viral licensing because it did exactly what it was supposed to. There was some weird sort of entitlement complex going on where people felt entitled not only to use open source but that it was somehow unfair that they couldn't also violate the terms and conditions of using it. I was similarly perplexed by the reaction back then too.
elric 3y ago
Some organizations (IBM/Eclipse) require signing agreements before you can even log an issue on their bug tracker. It's a pain, and I really can't be arsed.
- JohnFen 3y ago
  Yes, those are crazy policies. In effect, all they're saying is "we don't want bug reports".
phkahler 3y ago
We used to have a CLA for Solvespace (CAD) which is under the GPL3 license. There was some pressure to eliminate it, and some practical reasons as well so we dropped it. Since then, both FreeCAD (assembly 3) and Blender (via CAD sketcher add-on) have been using our constraint solver to great effect. Unfortunately they will probably never be able to tightly integrate it because both those projects are under GPLv2. I suspect we could offer that solver under another that license if those projects really wanted to go with it, but we no longer have a CLA so relicensing or dual licensing is off the table. On a related note, this is why proliferation of FLOSS licenses is bad - it prevents smooth code sharing between projects. Use MIT, BSD, GPL3, or LGPL and call it a day. I'm still not sure how "compatibility" actually works.
- regularfry 3y ago
  I think I'm right in saying that the FreeCAD integration problem could be solved on the solvespace side by relicensing the solver library as LGPL while retaining the GPL for the solvespace application itself. That keeps the set of licenses within your list, and applies the one intended for libraries to the library component. I'm sure that's been suggested and rejected before though - what's your take?
  - phkahler 3y ago
    >> relicensing the solver library as LGPL My take is that's still not possible because we dropped the CLA. In the past it may have been unlikely because the original author offered the solver under paid terms for commercial use and LGPL would allow commercial use without paying. I'm not sure what my own contribution to that part is, but I'd sooner offer GPLv2 as an option over LGPL.
    - regularfry 3y ago
      Got it. That makes sense.
- jcelerier 3y ago
  Many projects without a CLA could relicense though, e.g. LLVM
gavinhoward 3y ago
I agree with this, but at the same time, that's exactly why I will have a CLA. I am a one-man shop. I struggle to read code written by others because I struggle to build theory of mind. So I do not want your contributions. My CLA is supposed to drive you away from giving them to me. But on the flip side, I also want to be able to give commercial licenses to customers instead of the current AGPL-like license I have. For that, I need a CLA. I also want to relicense to more permissive ones in the future after I'm established. I also want to release my stuff into the public domain on my death. For that, I need a CLA. So I apologize, but my CLA is meant to stop you from contributing, but it's also important for making things more permissive later.
- electroly 3y ago
  If you don't have any other contributors, you're free to offer any license to anyone you'd like. Simply not accepting contributions will do the trick; you don't also need a CLA in that situation. It doesn't make sense to have a CLA for a project that doesn't accept contributions.
  - gavinhoward 3y ago
    The CLA is really for corporate customers who give me bug fixes for their environments.
    - JohnFen 3y ago
      So then, you do want contributions.
      - gavinhoward 3y ago
        No, but customers may have environments that I cannot reproduce.
- pydry 3y ago
  If you dont want contributions you dont need a CLA. You just dont accept them.
ndorf 3y ago
HN is somehow always timely. Currently, these folks expect me to sign a CLA for a one-byte change to their README: https://github.com/gravitl/netmaker/pull/2516 https://github.com/gravitl/netmaker/pull/2516
- cxr 3y ago
  This is amazing. (Note for the reader: look at the change <https://github.com/gravitl/netmaker/pull/2516/commits/196b1fecd38d2ff2e51cf2346e5ad95f108174bd https://github.com/gravitl/netmaker/pull/2516/commits/196b1f...>). There is so little that you stand to gain by agreeing to the CLA (and so much downside for them if they reject it and keep the status quo) that the best thing would be to say no. And I hope that if they do keep it as-is and then someone comes along later and makes the fix, you hound them about violating your IP and cite their comment "we do not have the rights" as prima facie evidence. Make CLA worshippers bite the bullet on their goofy beliefs.
  - ndorf 3y ago
    I cannot sign the CLA since per its own terms, I would have to get written permission from my employer. Luckily, as I wrote, the change is not copyrightable and no one, including myself or my employer, can claim copyright ownership over it.
    - cxr 3y ago
      > the change is not copyrightable Right. > no one, including myself or my employer, can claim copyright ownership over it People can claim anything they want. Whether they're correct is the thing. I'm suggesting that, since they've articulated a belief that they can't use it without an explicit CLA, you go ahead and yes-and them and play it out both for comedy's sake and the greater good.
      - ndorf 3y ago
        I am sympathetic to that view, however, I have no desire to "punish" the authors for choosing to use a CLA in this case. I am not going to waste the time of multiple people at my day job to get this approved, however. Nor do I want my mental health called into question at work, which would be a predictable result of making such a request.
halostatue 3y ago
For the open source projects I manage related to $DAYJOB, we require DCO signoffs using the `Signed-off-by` signature in commits. https://developercertificate.org https://developercertificate.org (We have a GitHub action that verifies this, based on another action, based on something by Probot. Ours has been modified to allow automatic DCO certification for people from the company.)
- remram 3y ago
  What does a "signed-off-by: " do? Unless you use a "signed-the-agreement:" what is this trailer supposed to indicate?
hgs3 3y ago
Worth mentioning that even the FSF requires copyright assignment [1] [2]. [1] https://www.gnu.org/licenses/why-assign.en.html https://www.gnu.org/licenses/why-assign.en.html [2] https://www.fsf.org/bulletin/2022/fall/copyright-assignment-with-the-fsf https://www.fsf.org/bulletin/2022/fall/copyright-assignment-...

60 points by pabs3 3y ago

I 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.

pjdesno 3y ago
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.
- tmpX7dMeXU 3y ago
  This feels like…one degree away from a no true Scotsman argument.
  - bkor 3y ago
    Why? Getting someone so sign off on a CLA is a huge burden. There are loads of companies that have huge software development teams but the company is NOT an IT company. Legal isn't setup to figure out a CLA. At least that's in my experience. It's significantly easier to not contribute back than spend ages trying to involve legal. Sort of like a barrier to entry, though maybe called a barrier to contribute.
- bruce511 3y ago
  Yeah, I would argue the projects requiring a CLA are exactly as you described - companies that want to keep specific future options on the table. OSS covers a wide spectrum of projects, from the Linux Kernel at the one end, to Frank's recent half-assed attempt at a CSS editor. Clearly no statement is going to cover everything. The set of projects that require a CLA, and the set of pseudo OSS projects has a high degree of overlap.

remram 3y ago

I'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.

cxr 3y ago
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 https://github.com/neovim/neovim/issues/3036>
- deleted 3y ago
  [deleted]
- williamvds 3y ago
  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.

milliams 3y ago

This is where I like the FSFE's Fiduciary License Agreement (https://fsfe.org/activities/fla/fla.en.html 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/ https://ev.kde.org/rules/fla/).

rurban 3y ago
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-frequently-asked-questions-faq-guide https://www.fsf.org/blogs/licensing/new-contributors-frequen...
- aragilar 3y ago
  FSF != FSFE.
  - rurban 3y ago
    I do hope very much. FSFE is the evil empire, the FSF the good one
    - remram 3y ago
      It seems like you might have meant the opposite, based on your previous remark? Did you?

deleted 3y ago

[deleted]

amtamt 3y ago

Can there be somewhat standardized CLAs, along the lines of Apache/ MIT... licenses?

bkor 3y ago
I'm aware of the following: https://harmonyagreements.org/ https://harmonyagreements.org/ Still, CLAs are a barrier on their own already. Standardizing them doesn't help. Plus as another commenter mentioned: sometimes a standard CLA is used but then various bits aren't filled in.
- hgs3 3y ago
  Standardizing CLA's helps the same way standardizing software licenses helps prevent license proliferation [1]. Code hosting websites, like GitHub, should provide a mechanism for registered users to electronically sign a CLA from their web interface. No hassle, no unfilled bits, and you've got a 3rd party (e.g. GitHub) notarizing the contract. [1] https://en.wikipedia.org/wiki/License_proliferation https://en.wikipedia.org/wiki/License_proliferation
  - cxr 3y ago
    The solution to CLA proliferation is not the proliferation of CLA use, which is what your suggestion involves. If you want to solve CLA proliferation, it's as easy as not going out of your way to add a CLA to your project followed by insisting that people sign it. Let the strength of the license (and your faith in the choice of license) stand on its own.

bmitc 3y ago

How is a CLA any different of a legal agreement than agreeing to a license? The CLAs I have seen basically boil down to the project maintainers maintaining ownership of the code, ability to adjust the license if desired, and protect them from people contributing code that the contributor doesn't have the rights for. I have seen projects suffer from single contributors stubbornly refusing to budge on relicensing, even if the relicense would benefit the project.

A1kmm 3y ago
If I contribute to an AGPL project and license my changes back to you under AGPL, that means you can't one day decide to start selling my changes together with a closed-source module; the copyleft works to protect me against you deciding to take my changes closed-source, not just to protect the original maintainer from that. If I contribute to an AGPL project and sign a CLA that assigns copyright to you, you might announce tomorrow that you are going to run off with my contribution and start only releasing new versions under a non-FOSS licence. This fear applies particularly if you are a for-profit company who might one day lose your desire to do FOSS. This exact thing, in fact (other than the AGPL part anyway) happened recently with just about every Hashicorp project - so it is not just some hypothetical fear. I would not contribute (unless I was being paid) to someone else's project unless there was no CLA (inbound = outbound licensing), or they were a not-for-profit with appropriate constitutional limitations on profit-seeking behaviour.
- pydry 3y ago
  >If I contribute to an AGPL project and sign a CLA that assigns copyright to you, you might announce tomorrow that you are going to run off with my contribution and start only releasing new versions under a non-FOSS licence. That is generally the point of a CLA. If that bothers you you're supposed to not contribute and not sign. The up side is that that revenue model might mean that they can pay people to do that work instead of relying upon drive by pull requests and maintainers dedicating their time for free. Back in the early days of open source I saw a lot of people get mad at viral licensing because it did exactly what it was supposed to. There was some weird sort of entitlement complex going on where people felt entitled not only to use open source but that it was somehow unfair that they couldn't also violate the terms and conditions of using it. I was similarly perplexed by the reaction back then too.

elric 3y ago

Some organizations (IBM/Eclipse) require signing agreements before you can even log an issue on their bug tracker. It's a pain, and I really can't be arsed.

JohnFen 3y ago
Yes, those are crazy policies. In effect, all they're saying is "we don't want bug reports".

phkahler 3y ago

We used to have a CLA for Solvespace (CAD) which is under the GPL3 license. There was some pressure to eliminate it, and some practical reasons as well so we dropped it. Since then, both FreeCAD (assembly 3) and Blender (via CAD sketcher add-on) have been using our constraint solver to great effect. Unfortunately they will probably never be able to tightly integrate it because both those projects are under GPLv2. I suspect we could offer that solver under another that license if those projects really wanted to go with it, but we no longer have a CLA so relicensing or dual licensing is off the table. On a related note, this is why proliferation of FLOSS licenses is bad - it prevents smooth code sharing between projects. Use MIT, BSD, GPL3, or LGPL and call it a day. I'm still not sure how "compatibility" actually works.

regularfry 3y ago
I think I'm right in saying that the FreeCAD integration problem could be solved on the solvespace side by relicensing the solver library as LGPL while retaining the GPL for the solvespace application itself. That keeps the set of licenses within your list, and applies the one intended for libraries to the library component. I'm sure that's been suggested and rejected before though - what's your take?
- phkahler 3y ago
  >> relicensing the solver library as LGPL My take is that's still not possible because we dropped the CLA. In the past it may have been unlikely because the original author offered the solver under paid terms for commercial use and LGPL would allow commercial use without paying. I'm not sure what my own contribution to that part is, but I'd sooner offer GPLv2 as an option over LGPL.
  - regularfry 3y ago
    Got it. That makes sense.
jcelerier 3y ago
Many projects without a CLA could relicense though, e.g. LLVM

gavinhoward 3y ago

I agree with this, but at the same time, that's exactly why I will have a CLA. I am a one-man shop. I struggle to read code written by others because I struggle to build theory of mind. So I do not want your contributions. My CLA is supposed to drive you away from giving them to me. But on the flip side, I also want to be able to give commercial licenses to customers instead of the current AGPL-like license I have. For that, I need a CLA. I also want to relicense to more permissive ones in the future after I'm established. I also want to release my stuff into the public domain on my death. For that, I need a CLA. So I apologize, but my CLA is meant to stop you from contributing, but it's also important for making things more permissive later.

electroly 3y ago
If you don't have any other contributors, you're free to offer any license to anyone you'd like. Simply not accepting contributions will do the trick; you don't also need a CLA in that situation. It doesn't make sense to have a CLA for a project that doesn't accept contributions.
- gavinhoward 3y ago
  The CLA is really for corporate customers who give me bug fixes for their environments.
  - JohnFen 3y ago
    So then, you do want contributions.
    - gavinhoward 3y ago
      No, but customers may have environments that I cannot reproduce.
pydry 3y ago
If you dont want contributions you dont need a CLA. You just dont accept them.

ndorf 3y ago

HN is somehow always timely. Currently, these folks expect me to sign a CLA for a one-byte change to their README: https://github.com/gravitl/netmaker/pull/2516 https://github.com/gravitl/netmaker/pull/2516

cxr 3y ago
This is amazing. (Note for the reader: look at the change <https://github.com/gravitl/netmaker/pull/2516/commits/196b1fecd38d2ff2e51cf2346e5ad95f108174bd https://github.com/gravitl/netmaker/pull/2516/commits/196b1f...>). There is so little that you stand to gain by agreeing to the CLA (and so much downside for them if they reject it and keep the status quo) that the best thing would be to say no. And I hope that if they do keep it as-is and then someone comes along later and makes the fix, you hound them about violating your IP and cite their comment "we do not have the rights" as prima facie evidence. Make CLA worshippers bite the bullet on their goofy beliefs.
- ndorf 3y ago
  I cannot sign the CLA since per its own terms, I would have to get written permission from my employer. Luckily, as I wrote, the change is not copyrightable and no one, including myself or my employer, can claim copyright ownership over it.
  - cxr 3y ago
    > the change is not copyrightable Right. > no one, including myself or my employer, can claim copyright ownership over it People can claim anything they want. Whether they're correct is the thing. I'm suggesting that, since they've articulated a belief that they can't use it without an explicit CLA, you go ahead and yes-and them and play it out both for comedy's sake and the greater good.
    - ndorf 3y ago
      I am sympathetic to that view, however, I have no desire to "punish" the authors for choosing to use a CLA in this case. I am not going to waste the time of multiple people at my day job to get this approved, however. Nor do I want my mental health called into question at work, which would be a predictable result of making such a request.

halostatue 3y ago

For the open source projects I manage related to $DAYJOB, we require DCO signoffs using the `Signed-off-by` signature in commits. https://developercertificate.org https://developercertificate.org (We have a GitHub action that verifies this, based on another action, based on something by Probot. Ours has been modified to allow automatic DCO certification for people from the company.)

remram 3y ago
What does a "signed-off-by: " do? Unless you use a "signed-the-agreement:" what is this trailer supposed to indicate?

hgs3 3y ago

Worth mentioning that even the FSF requires copyright assignment [1] [2]. [1] https://www.gnu.org/licenses/why-assign.en.html https://www.gnu.org/licenses/why-assign.en.html [2] https://www.fsf.org/bulletin/2022/fall/copyright-assignment-with-the-fsf https://www.fsf.org/bulletin/2022/fall/copyright-assignment-...