Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> it makes people less likely to want to contribute to the project, because they probably feel like they are being taken advantage of or losing some right

I think it depends who the copyright is assigned to. I imagine people will have strong reservations about transferring copyright to a private company or individual.

But if the copyright is assigned to a mutually trusted organisation like a FLOSS foundation then I can't think of a good reason that a contributor would withhold copyright assignment.

They have nothing to lose and the project they care about will gain. There are even tools nowadays like CLAHub to make the process more convenient.

One exception might be corporate restrictions on contributors. Like if you need permission from your boss and it is denied.

I think the bigger issue with FLOSS projects is that often people are not always able to agree on an acceptable organisation to own the copyright let alone the kind of license to have.



> But if the copyright is assigned to a mutually trusted organization like a FLOSS foundation then I can't think of a good reason that a contributor would withhold copyright assignment.

How would one know beforehand what kind of license it will be re-licensed under in the future, and what kind of legal action that assigned copyright holder will take, which you may not agree with? You make valid arguments, but it's not that simple.

As a contributor it's easy to argue that there's no reason for something one contributes under license X to be put under license Y two years later without consent (not required in this case).


Copyright assignment isn't binary. It's a contractual agreement like anything else. You can make requirements like "it will always be under copyleft" (which is what the FSF and some Apache projects do). You should avoid projects that ask for blanket copyright assignment on a copylefted work.


> it's easy to argue that there's no reason for something one contributes under license X to be put under license Y two years later without consent

The problem isn't for the individual contributor, it's the project itself. Let's say for some reason you use Apache 2.0 and then decide you want to add MIT for better compatability with other license. You as the maintainer solicit from all contributors they're approval and you get 99/100, one person holds out and blocks it. What do you do in this case? Go back and remove all their contributions such that you can then continue with the general agreement?

A clause I've been considering, if it doesn't exist somewhere, is to have a majority rules portion to the agreement. But I'm not sure if this works without assigning copyright to the project.


> What do you do in this case? Go back and remove all their contributions such that you can then continue with the general agreement?

Yes, that's what you do, and it's the same in other industries.

For example, when Erlang/OTP contributors were asked to accept re-licensing under Apache2, a couple patches submitted by Netflix's Rick Reed were reverted prior to re-licensing because they didn't sign off.

The license is for all parties, not just to get contributions and then later do with it what you want. If that's how the project is governed, then the license has to reflect that (GPL3 or later) or a CLA must be in place. When that's clear, it's evident to contributors and many will refuse to contribute.


The whole point is to choose someone that you believe will make appropriate licensing decisions, both now and in the future. And that requires trust in the copyright holder. You cannot perfectly guarantee they will always do the right thing. But the legal structure of the organization can often reduce the risk of that.


I mostly agree, but unlike other legal agreements, contributing to a project under a FOSS license is not usually coupled with an expiry date after which there's room for radical re-licensing.


This is a really great point. Should there be a pay-to-play portion on these, e.g. Your copyright will "expire" and revert to the project(?) Should you not commit changes for a period of 2 years.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: