DCO and contributing file from CodiMD?

[SISheogorath]

We use a DCO in the CodiMD repo to simplify the legal status of code.

We could apply this here as well, it doesn't hurt, is easy to adapt and we could also link the CONTRIBUTING.md in the README.

As I'll focus on CodiMD when it comes to development, I don't want to tell you how you should develop your code, so I will leave the decision to the developers and users of this repository.

[pirate]

I apologize the trouble, but you can count me out if you're adding DCOs.

This is a hard moral stance I have against making the friction for new developers higher without actually providing any legal benefit over PGP signing. Many projects just hop on the bandwagon because they see huge FOSS projects that have been hit by lawsuits adding them, but it should not be a common practice for your run of the mill project on Github imo.

I already have a few bugfixes and improvement PRs that I've neglected pushing to codimd because of the DCO system, if you guys ever reconsider and remove it I'd be happy to push them, but for now I'm running on a personal fork.

[Ppjet6]

I genuinely don't understand what you are saying about the DCO. Are you saying git commit -s is a higher barrier of entry than setting up PGP?

After all the DCO is really just putting your name on a patch and saying you have rights to be pushing it to the project, I'm not entirely sure what the issue is. That's something you will likely be doing anyway.

Note, I don't know anything about bandwagon and fashion around DCOs, so please don't count me in that lot.

[pirate]

I'm writing a post that goes into detail about my reasoning against CLAs/DCOs, but many of my arguments are covered by Bryan Cantrill's talks and articles if you're curious:

• https://www.joyent.com/blog/broadening-node-js-contributions
• https://www.youtube.com/watch?v=Pm8P4oCIY3g

[SISheogorath]

DCO, other than CLA, doesn't grant ownership. All DCO does explicitly stating, that whatever you commit there is made by you or you at least got the permission to publish it under the license the project uses. This doesn't shift ownership from you to a company/project, but shifts responsibility for code you contributed from a company/project to you as a contributor.

That's an important difference. And other than a regular commit, this is not implicit, but by providing a sign-off it's an explicit statement. And being easy to fake or not, at the end of the day, that's up to a court. Important is, that a sign-off line is an explicit statement and this way, from a legal perspective, definite.

https://opensource.com/article/18/3/cla-vs-dco-whats-difference

[Ppjet6]

Hey @pirate, thanks for answering.

The article you cite actually praises DCOs. Maybe have a look at what @SISheogorath linked.

as with Linux, contributors hold copyright to their own contributions and agree to license it under the prevailing terms of the source base.

Linux is using a DCO.

[pirate]

Yup, I'm aware of the difference, but the arguments against them overlap: it's a barrier to entry for contributors that increases friction for people trying to help improve the project.

Thanks for those links, I will read them thoroughly before posting my article. Who knows, I might change my mind still!

My main argument is that we can design our licenses or PR workflow better such that additional steps during the contribution flow aren't required from developers.

Possible solutions besides commit sign-off include:

• a clause in the license that entails contributors sign off just by contributing
• a clause in the license saying individual developers are liable for any consequences of stolen code, and not the project
• a PR template with a checkbox that the developer checks saying "I didn't steal this code"

This is a valuable discussion and I really appreciate both your patience with me, I know many projects would probably just ban me and say "take it or leave it".

[SISheogorath]

• a clause in the license that entails contributors sign off just by contributing
• a clause in the license saying individual developers are liable for any consequences of stolen code, and not the project

Main problem here again: It's implicit and a user could pretend to not being aware of it. That's also the reason why you usually have to check this (maybe annoying) checkbox asking you for reading the terms and conditions when you sign up anywhere.

• a PR template with a checkbox that the developer checks saying "I didn't steal this code"

Yes, that would actually work…! …until you decide to switch the platform at any point in time. Issues, Pull Requests, Mile stones, … all things GitHub provides around a repository is gone as soon as you move to another platform or a private mirror. And while you can take some information with you, how do you map it back to their original authors? This brings us back to the point where commits are more persistent and easier to handle. and signing off commits is something you can also do an the web interface.

All those legal things are quite tricky and sometimes contra intuitive, and as already mentioned, those terms and conditions are known to be not read, still people have to check that they read them and the organization is fine.

---

You are may also interested in: https://penguindreams.org/blog/why-i-dont-sign-non-competes/

And yes, in general I agree with the barrier but we could always find one, if we want (for example the need for a GitHub account to contribute). What we should try is to find a balance between usability and risks we put ourselves at. Copyright liability is a quite ugly one, which is a reason that I advocate for DCOs which seems to be a quite good solution for this problem.

But at the end of the day it's up to each of us to make our mind about it :smile:

[ccoenen]

First and foremost: this may be the most constructive debate I have witnessed on the internet :-D

a PR template with a checkbox that the developer checks saying "I didn't steal this code"

Generally, this mostly describes the sign-off. On the command line, it's the closest thing to a checkbox: a command line flag (-s). For many GUI clients (I checked sourcetree, git tower and git gui, the latter ones being pictured below) it is a checkbox or button.

It is true that we do have to explain this to a lot of new contributors and that this creates friction.

[pirate]

Now that CodiMD is entirely open-source and not linked to a legal, sueable entity using code for-profit, does the DCO still matter?