Did PieFed 'steal code' from Pylova? Let's look at what happened - PieFed
join.piefed.social
This is my first open source project, apart from tiny bits of code that no one ever paid any attention to. Maybe I don’t know how to do open source properly, maybe I made a mistake here. Let’s find out. A few months ago, someone made a new fork of PieFed, which they called ‘Pylova‘. […]

This is my first open source project, apart from tiny bits of code that no one ever paid any attention to. Maybe I don’t know how to do open source properly, maybe I made a mistake here. Let’s find out.

  • INeedMana@piefed.zipEnglish
    1·
    3 months ago

    I think the main thing here is the timing and context

    The fork became into existence during the split in Piefed community around May (IYKYK). I think that the way you played out this incorporation of the code might have felt as erasure of contribution. It’s not about the code or licenses. It’s about how we treat each other. As far as I read the room, the fork became because of what was happening, not because of having a different vision. It came into existence, so those who could no longer type in Matrix support channels could still affect how the software they are running behaves. And then the mainline, they were (socially-wise) barred from influencing, copied some of their changes. And some with another author on the commit.
    PyLova being a fork, you could have cherry-picked the commits. It keeps original authors. The first copy via a patch that kept attribution was better.
    With the stuff going on in the background you could have asked in an issue if they are ok with you taking these parts. Legally they probably couldn’t say no, but people-wise sometimes the point is if someone asks.
    You also could have mentioned them in commit message.

    Without that context, I think just copying the code would be ok. As far as my understanding goes, it is one of the core ideas behind open-source that improvements are not gate-kept behind the will of the one doing the improvement to share or not. Maybe a mention in the merge commit message or the first commit of the copy would be a polite thing to do.
    But with the context of what was happening in the background, I think it might have felt first as “you go play away from us, you’re on your own, good luck” and then “oh, good idea. I’m gonna present it as my own”
    Again, my take is about feelings and participating in communities. Not laws and licenses

  • one_old_coder@piefed.socialEnglish
    0·
    3 months ago

    The only missing part was the copyright from the original project, or some kind of attribution. But you’re always free to steal code from an open-source project if you both have the same license.

    • turdas@suppo.fiEnglish
      0·
      3 months ago

      Yeah this is ridiculous. Neither project has copyright notices in preamble comments at the top of files, or an AUTHORS.txt, or any other kind of copyright notice. Therefore there is no copyright notice to preserve as stipulated by the AGPL. While it’s best practice to preserve Git authorship by using properly formatted patch files (like he did for the first commit), this isn’t technically required.

      It’s also debatable whether the stylesheets copied here are even substantial enough works to qualify for copyright to begin with, but that’s another discussion.

      The Piefed author should merge all that code right back in, but use git format-patch for both commits so Git authorship is preserved. If the fork fellas don’t like that, they should shutter their fork and go fork a project with a more permissive license that allows them to relicense to closed source.

      edit: I imagine the only reason the Pylova fork authors even cared or noticed is that the stylesheet commit showed up as a merge conflict when they were merging in upstream code – something that would not have happened if the code was merged in using a proper patch file. My guess is that there was a game of broken telephone at play here when the Piefed author heard about this from some third party.

      • mschae@discuss.mschae23.deEnglish
        1·
        3 months ago

        The Piefed author should merge all that code right back in, but use git format-patch for both commits so Git authorship is preserved.

        Instead of doing that, I’d just fetch their commits and merge them directly. That has the added benefit of not generating new commits with new hashes (making it easier on the fork’s side). If the original commits were signed, it would also preserve those signatures.

        Neither project has copyright notices in preamble comments at the top of files, or an AUTHORS.txt, or any other kind of copyright notice. Therefore there is no copyright notice to preserve as stipulated by the AGPL.

        Agreed on this part though. Although the license, under section 5, states “a) The work must carry prominent notices stating that you modified it, and giving a relevant date.” One could maybe argue this wasn’t done for the second change, but if that were to be merged in properly with git attribution intact (which also includes timestamps), that should also be fine.

        I had a browse of what they’d done and saw something cool that I wanted PieFed to have too […]

        This is definitely in line with the free software philosophy. It should be possible to include others’ improvements to your project, if you’ve already got their modified source code. And “stealing” code is not even a thing (it’s copyright infringement at worst, never theft).