Don’t sign a CLA • Hacker News Board

Re: Don’t sign a CLA

#181

Post by v_lisivka » Fri, Oct 05, 2018, 11:55 PM UTC

eridius wrote: post #180

v_lisivka wrote: post #178

Earlier quoted context omitted.

But Copyleft license significantly increases my freedom as a developer. I can develop software for customer#1, then use same software with customer#2, and so on. It's free. It's like "those people told me that they are free, but I cannot sell them, so in reality they are non-free".

You could develop software for customer#1 and use the same software for customer#2 with a non-Copyleft license too. The question isn't "does the license enforce that the source must be distributed", it's "will the customer allow me to release the work as open source to begin with". About the only way Copyleft applies here is if you can make a strong case that the work customer#1 wants you to do necessitates (or would…

> You could develop software for customer#1 and use the same software for customer#2 with a non-Copyleft license too.

No, I cannot. Work done for hire is owned by the employer, not the employee. But, if employer chose GPL-covered software, e.g. Linux kernel, then he is forced to release code under GPL, so I can develop my code, e.g. kernel module for customer #1 and then use it with customer#2, because GPL protects my freedom. I don't need to reinvent the wheel, like with proprietary code.

Re: Don’t sign a CLA

#182

Post by hoistbypetard » Fri, Oct 05, 2018, 11:59 PM UTC

Legogris wrote: post #4

It's a great point to be aware of, but the title and the tone implies that you as a contributor should be a FOSS maximalist. As they say, not all open source is FOSS. And some people are OK with that. Let them contribute, as long as they are aware of the implications. When I discover bugs in open-source projects during my day job (which is on a closed-source project), I will be much happier having those fixes merged…

> When I discover bugs in open-source projects during my day job (which is on a closed-source project), I will be much happier having those fixes merged upstream than having to maintain our own private fork.

And this, regardless of how you weigh the post's other objections to a CLA, is a very good reason to sign one for many contributions.

Re: Don’t sign a CLA

#183

Post by kemitchell » Sat, Oct 06, 2018, 12:00 AM UTC

orthecreedence wrote: post #161

Hi, I run an open source project and it has a CLA. I chose a fairly permissive one (contributors retain ownership/copyright), however it does allow relicensing. One of the main reasons I chose to do this is: 1. I have a put a lot of time into the project. More than anybody. Years of work. At some point, I'd like to be able to make money off of it, and relicensing will give me that option (enterprise installations and…

re iOS store, have a look at: https://github.com/signalapp/libsignal-protocol-c#license

If you need legal advice for your specific project and situation, speak to a lawyer.

Re: Don’t sign a CLA

#184

Post by pron » Sat, Oct 06, 2018, 12:45 AM UTC

It's not so much signing away your rights as getting something in exchange for something. As you say, you can always fork the project, but very often large projects (that tend to be the ones with CLAs) are also used by companies that rely on them. What you get in exchange for the CLA is your code (written to scratch your itch) becoming part of the mainline, and saving you the trouble of merging with every update. If scratching your own itch is the goal, and if your contribution is small relative to the total project (and it often is for projects with CLAs), then granting the project leaders a joint ownership over copyright is a very small price to pay in exchange for having the leaders take your contribution into the mainline. If, on the other hand, your goal is to shape the project, this usually entails a large number of significant contributions, and if you do that, becoming a part of the leadership or getting a part of the project ownership can be negotiated.

Re: Don’t sign a CLA

#185

Post by carapace » Sat, Oct 06, 2018, 1:29 AM UTC

An obscure but interesting point, by DJB:

> In the United States, once you own a copy of a program, you can back it up, compile it, run it, and even modify it as necessary, without permission from the copyright holder.

...

> Once you've legally downloaded a program, you can compile it. You can run it. You can modify it. You can distribute your patches for other people to use. ... As long as you're not distributing the software, you have nothing to worry about.

https://cr.yp.to/softwarelaw.html

Re: Don’t sign a CLA

#186

Post by kbutler » Sat, Oct 06, 2018, 2:43 AM UTC

v_lisivka wrote: post #181

eridius wrote: post #180

Earlier quoted context omitted.

You could develop software for customer#1 and use the same software for customer#2 with a non-Copyleft license too. The question isn't "does the license enforce that the source must be distributed", it's "will the customer allow me to release the work as open source to begin with". About the only way Copyleft applies here is if you can make a strong case that the work customer#1 wants you to do necessitates (or would…

> You could develop software for customer#1 and use the same software for customer#2 with a non-Copyleft license too. No, I cannot. Work done for hire is owned by the employer, not the employee. But, if employer chose GPL-covered software, e.g. Linux kernel, then he is forced to release code under GPL, so I can develop my code, e.g. kernel module for customer #1 and then use it with customer#2, because GPL protects m…

Depends on the relationship and contracts in place. If he said employer#1 and employer#2, yes, that's a problem.

"Customer" implies a much looser relationship, but you should still make sure appropriate contracts defining ownership are in place.

Re: Don’t sign a CLA

#187

Post by sanderjd » Sat, Oct 06, 2018, 3:03 AM UTC

JoshTriplett wrote: post #150

zaroth wrote: post #143

Earlier quoted context omitted.

Oh well, if you say so! The point is the adjective is commonly used imprecisely, despite a minority’s desire for it to be only used to describe a precise circumstance. Genie, meet bottle.

> despite a minority’s desire for it to be only used to describe a precise circumstance. The vast majority of the software industry uses "open source" correctly. A small minority of people and companies with a vested interest in sowing confusion to promote their "source available" business models misuses the term and creates FUD.

This wasn't really my experience... I went to school for CS, which involved using a bunch of open and closed source tools of different kinds. I wasn't aware of the distinctions between different kinds of open source, some of which fell within the OSI definition and some of which did not, I just knew that closed source stuff where I couldn't read the source was more annoying when things went wrong. I remember the moment much later when I realized that there was this whole (weird, to me) turf war over the definition. It still seems to me that the most straightforward definition of "open source" is just any software for which the source code is available (such that it is open, like a book).

Re: Don’t sign a CLA

#188

Post by newacctjhro » Sat, Oct 06, 2018, 3:35 AM UTC

zaroth wrote: post #143

phoe-krk wrote: post #135

Earlier quoted context omitted.

No. "Source available" is not the same as "open source". https://haacked.com/archive/2006/07/26/CodeAvailableVsOpenSo...

Oh well, if you say so! The point is the adjective is commonly used imprecisely, despite a minority’s desire for it to be only used to describe a precise circumstance. Genie, meet bottle.

This confusion/imprecision is only common among non-technical people. When a software project describes themselves as open source, in the overwhelming majority of cases they actually mean this https://opensource.org/osd-annotated

Re: Don’t sign a CLA

#189

Post by newacctjhro » Sat, Oct 06, 2018, 3:42 AM UTC

mikeash wrote: post #179

justincormack wrote: post #176

Earlier quoted context omitted.

It does not permit relicensing. You may use it in an aggregate work with other pieces that have a different license, including proprietary or GPL, but that does not mean your code is relicensed.

Is there an actual difference there, or is this just semantics?

You can't take the code as-is and turn it into proprietary code. You need to build a derivative work that contains the permissive code plus some other proprietary stuff.

Re: Don’t sign a CLA

#190

Post by eridius » Sat, Oct 06, 2018, 7:11 AM UTC

v_lisivka wrote: post #181

eridius wrote: post #180

Earlier quoted context omitted.

You could develop software for customer#1 and use the same software for customer#2 with a non-Copyleft license too. The question isn't "does the license enforce that the source must be distributed", it's "will the customer allow me to release the work as open source to begin with". About the only way Copyleft applies here is if you can make a strong case that the work customer#1 wants you to do necessitates (or would…

> You could develop software for customer#1 and use the same software for customer#2 with a non-Copyleft license too. No, I cannot. Work done for hire is owned by the employer, not the employee. But, if employer chose GPL-covered software, e.g. Linux kernel, then he is forced to release code under GPL, so I can develop my code, e.g. kernel module for customer #1 and then use it with customer#2, because GPL protects m…

If the employer chooses any open-source license whatsoever then you can use the code with the next customer (assuming the next customer is ok with the license). There's nothing special about Copyleft licenses there. Well, except for the fact that a Copyleft license is far more likely to have customer#2 say "no you can't use that, it's GPL, are you crazy?"