Devin BARTON

I am an avid Linux lover and open source enthusiast. I use Ubuntu and believe in sharing knowledge. Apart from Linux, I love classic detective mysteries.

17 thoughts on “Never Sign A Contributor Licence Agreement

  • June 11, 2021 at 11:11 am
    Permalink

    Fanatic, there still no are a problem, because if the company or new owner makes a "evil" thing you can always fork if needed, so there is no problem and they should change from GPLs (trash) to MPL.

    Reply
  • June 11, 2021 at 11:11 am
    Permalink

    I think we need a better license
    Once FOSS it should stay FOSS & the only licenses a FOSS project shoukd be allowed to change to are other FOSS licenses

    & ONLY the original creators should be allowed to change licenses

    Anyway this could be an oppurtunity to fork Audacity & rewrite it in C or RUST or hell even SHELL or ASM
    We could add more cool features & make it even more lightweight
    While we are at it let's implement the codes in LMMS
    It's an open source DAW ( Digital Audio Workstation)

    Reply
  • June 11, 2021 at 11:11 am
    Permalink

    You forgot to mention that what you're saying only applies if the project has a copyleft licence in the first place. Also if you get paid to contribute, you normally don't care about that stuff either

    Reply
  • June 11, 2021 at 11:11 am
    Permalink

    Everyone else is talking about forking audacity to make sure this can't happen. But the problem is that with the CLA, they can make it illegal to fork Audacity, right? If they rewrite the 10% of code they need to or whatever and re-release it under only a proprietary license, then it is illegal to use the 90% of code they got under CLA in any other project right? Or is this not how it works.
    I guess if that was how it worked it wouldn't make sense, because then prior forks would retroactively become illegal, but GPLv2 expressely gives forkers a copy of the original license over the code:
    "Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein."
    But that's how I interpret it when they say the code would change to become proprietary licensed only.

    Reply
  • June 11, 2021 at 11:11 am
    Permalink

    I believe CLA has its place. As long as project team is clear and open with CLA with their contributors. I totally hate someone who hides true CLA behind convoluted language.

    If there is no CLA, then there are just assumptions and good faith. If there is a CLA I would know wether I should contribute or not.
    This may be an unpopular opinion but I personally believe that once code is contributed and merged, it is part of entire codebase. Other than a permanent public record of contribution, and some bounty or gift associated with that contribution, I don't expect or demand anything from project.

    DCO is a good alternative, maybe a lighter version of it for small project. But CLA, if its not shady, can actually be good for project and community as whole.

    Reply
  • June 11, 2021 at 11:11 am
    Permalink

    There's something I'm not understanding here, let's assume that 100% of Audacity's code is owned by Muse under the CLA. If at some point, Muse decides to change the project's license (even a proprietary one), will this apply to all commits? Or just new commits added from this point? In the case the project becomes proprietary, will this make it un-forkable?

    Reply
  • June 11, 2021 at 11:11 am
    Permalink

    CLA are useful for larger projects tho, there are often driveby contributors that do a small contribution and then disappear

    the linux kernel itself has an issue as a result of this, they can't update the license from GPLv2 to GPLv3 because they'd have to contact thousands of driveby contributors

    Reply
  • June 11, 2021 at 11:11 am
    Permalink

    A few questions: 1) Does that GPLv2 issue affect both the GPLv2-or-later and GPLv2-only? 2) How to get around that GPLv2 relicencing issue if we shouldn't use a CLA? 3) What's the risk to a project owner for not using a DCO or confirming any ownership of contributions?

    Reply
  • June 11, 2021 at 11:11 am
    Permalink

    The easiest way to explain it in my opinion is:
    1. Your code is not licensed as GPL, you give it to Audacity project.
    2. They release the code under GPL.
    3. They can decide to release the code under any license, because it is theirs.
    Is this correct? Or did I misunderstood something here. This is very similar to the professional scene when you work for a company. They want the power and freedom to do what they want. But that does not make sense in this context of free and open source projects.

    Reply
  • June 11, 2021 at 11:11 am
    Permalink

    I read the thumbnail as "This is why class is dangerous" and thinking if this is a programming video.

    Reply
  • June 11, 2021 at 11:11 am
    Permalink

    Im just waiting for the Audacity fork, if it doesnt exist already!

    Reply
  • June 11, 2021 at 11:11 am
    Permalink

    more like cringetributor license agreement. how bout i sign Bofa instead

    Reply

Leave a Reply