Slashdot Mirror


On the Ethics of a Code Split?

McWizard asks: "We've recently had a code split at a project I'm leading. (No name given, as this is a question, not an advertisement campaign). While both projects have done some major design decisions in opposing directions, we've been keeping a close eye on the changelog of the spinoff for small changes that could be used. So, whenever we've found an interesting piece of code (mostly GUI stuff, nothing longer than 20 lines of code), we transferred it to our project and gave credit to the spinoff team in the changelog. What does Slashdot say on that matter? Is this unethical or are such things fair game?" "Yesterday, I was contacted by the leader of the spinoff project who told me that he's quiet angry at us for doing that and that it's considered unethical and rude to copy code from the spinoff. As both projects are under the GPL, we have an opposing opinion on that matter and we've more than once invited him to copy code from our project. Nevertheless he's thinking about obfuscating his changelog and only open the source as packages when he's doing a release, which is, as he says, his right under the GPL."

5 of 448 comments (clear)

  1. No problem by perlionex · · Score: 5, Interesting

    Legally, there's nothing wrong since both projects are GPL'ed (I presume).

    Ethically, I don't see anything wrong with it. In the end, it's your design decisions that are going to make a difference, which is why the code split in the first place. In fact, there's no reason why both projects shouldn't take code from each other; if there are common areas where there's actually no disagreement, this will help to reduce duplication of effort.

  2. It doesn't matter... by Tsugumi · · Score: 4, Interesting
    whether you call it GPL or not. The idea here, folks, is to get shit done. The GPL et al is a handy way of making sure that you don't have to jump through hoops, or reinvent the wheel in order to get shit done - you just use the accumalated sum of human knowledge at your disposal to make things that people can use to do stuff.

    Can you imagine human history without being able to use other people's good ideas? I mean even if it's not derived? "I'm sorry, you can't have that steam train - I represent the estate of the ancient greeks, and we have a patent on the steam engine."

    Having said all that, accreditation is nice - aknowledge the work that people have done, it's cool that you are doing this. This is what polite people in academia do - just recognise the derivation of the idea, then use it with what you're doing.

    T

  3. I don't understand his problem. by Jaywalk · · Score: 4, Interesting
    I'm pretty rigid when it comes to ethical stuff, but where is the ethical dilemma in this? Unless you're taking trade secrets from a competitor or claiming that the new code is your own, there is no moral conflict involved. Sure, you're using someone else's work, but isn't that what code reuse is all about? It sounds more like Best Practices than an ethical problem.

    Arguably, it might have been more polically aware to ask permission before using the code, but I'd say the more serious problem is that the leader of the spinoff doesn't appear to fully understand the concept of the GPL. Anybody can take a project and expand on it. That code can, in turn, be added to any other project. It's all about sharing and showing your stuff, so someone using your code should be taken as a compliment, not theft.

    Maybe you could try and talk to him and ask why this is a problem; perhaps it's a matter that can be settled. In any case I wouldn't borrow any more of their code until the matter is cleared up since that would only escalate the feud.

    --
    ===== Murphy's Law is recursive. =====
  4. Forks are quite common by EmbeddedJanitor · · Score: 4, Interesting
    Forking happens more than people realise. Something I've seen a few times is A is the developer/maintainer of some code and B develops a new feature/fixes a bug etc and sends it back to A. A refuses to accept the patch. This forces B to fork or live withouth the patch.

    I've seen this happen in pretty important chunks of code - even gcc - which is pretty sad.

    As a maintainer for a file system, I try to treat people as "customers". Sure, unless they're paying, they don't have any legal rights, but there is still some moral obligation to serve. I try to add the features that people want without breaking the design goals etc. I'm sure this is easier with a file system which is very deeply buried than with a userpsace program where everybody has a beef about itty-bitty features.

    --
    Engineering is the art of compromise.
    1. Re:Forks are quite common by norwoodites · · Score: 5, Interesting

      The maintainer of gcc at that time was one person, Kenner, who said everytime someone submitted a patch, he would do a better patch next week. That is the reason for the split. Overly conservative is not the world for this, it was just plain stupid and a political mess.

      And it was more than just the cygnus people, it was also IBM and the fortran maintainer and other people too (yes IBM was involved with GCC before 1999) who founded EGCS, see about some of the history of EGCS project and GCC.

      SSP is also called propolice. The writter of it submitted it against a release branch which was the main reason why it got rejected and it was too big to review.