| |||||||||||
Linus on documenting patch provenanceLinus on documenting patch provenancePosted May 23, 2004 15:08 UTC (Sun) by leandro (guest, #1460)Parent article: Linus on documenting patch provenance Wouldn't it be just easier to get copy rights assignments, like per the FSF policy?
(Log in to post comments)
Not easier Posted May 23, 2004 16:40 UTC (Sun) by rfunk (subscriber, #4054) [Link] The FSF-style copyright assignment may (or may not) be better legally,but it's certainly not easier, since that would require a LOT more paperwork than a maintainer adding a single line to the patch description. Anyway, copyright assignment solves a different problem than Linus's solution does. Linus is trying to track the path a patch takes, not who owns it.
Not easier Posted May 24, 2004 4:02 UTC (Mon) by leandro (guest, #1460) [Link] > that would require a LOT more paperwork than a maintainer adding a single line to the patch description [...] Linus is trying to track the path a patch takes, not who owns it. The copy rights assignment thing automatically takes care of the path -- the person assigning the copy rights implicitly states he owns the code, so any misappropriation responsibily is pushed over to the contributor. Who BTW also gets properly identified.
Not easier Posted May 24, 2004 4:35 UTC (Mon) by rfunk (subscriber, #4054) [Link] Sure. It's still not easier to do copyright assignment.
Not easier Posted May 24, 2004 5:52 UTC (Mon) by JoeBuck (subscriber, #2330) [Link] It's not really a lot more paperwork; under the GNU scheme, each contributor would do paperwork only one time, at least until changing jobs, and then a new employer disclaimer is needed. Getting that first paperwork done, and getting the employer to agree, can be a hassle.
What about the trivial submitters? Posted May 24, 2004 12:00 UTC (Mon) by Duncan (guest, #6647) [Link] > It's not really a lot more paperwork [because]> each contributor would do paperwork only one time[.] Perhaps it /would/ be done only once per person-job. That doesn't eliminate the problem, however. Why? Because what we've then done is make it impossible for an individual to point to a problem and provide even a one-changed character patch (in the event of a detected typo, say), for the first and possibly last time in his life. There are a lot of this type of "trivial" submitters around. People who know C but don't really know the kernel. However, they use a driver that doesn't work, or quits working, take a look at the code, and despite not knowing much about the kernel, see something obvious and provide a bug report together with a patch that "works for them." Then they go on about their normal life, leaving the driver maintainer to check the patch, see that it is indeed a typo affecting a corner case that nobody ever caught before, and apply it. What we are now suggesting is that said "trivial" submitters could no longer submit anything, until they jumped thru a bunch of legal paperwork, that isn't really worth it for that one character. That's obviously an extreme example, but make it a 10-line change instead of single character change, and it's a significant amount of people over the course of a year, I'd guess. Of course, not having assigned copyright does therefore make it essentially impossible to ever change the license to the kernel in general, because it's going to be impossible to find all those <= 10-line submitters from over the years, but that's actually part of the object -- a practical guarantee that the kernel license can never and will never change. Duncan
What about the trivial submitters? Posted May 24, 2004 15:17 UTC (Mon) by bfields (subscriber, #19510) [Link] What we are now suggesting is that said "trivial" submitters could no longer submit anything, until they jumped thru a bunch of legal paperwork, that isn't really worth it for that one character. I don't think GNU has ever required that: http://www.gnu.org/prep/maintain_5.html In fact, it looks to me (I'm not really familiar with the process, just doing a google search on "site:www.gnu.org copyright assignment") like they have two levels short of full copyright assignment: for trivial contributions nothing may be required, for smaller contributions a disclaimer that's short of a copyright assignment may be sufficient. --Bruce Fields
What about the trivial submitters? Posted May 24, 2004 15:41 UTC (Mon) by madscientist (subscriber, #16861) [Link] Trivial submitters on the scale you describe (one changed character, or even 10 lines) does *not* require approval under the GNU guidelines. The GNU guidelines for developers say:> 4.2 Legally Significant Changes > If a person contributes more than around 15 lines of code and/or text Also, on copyright assignment: it's true that copyright is assigned to the FSF, but the FSF grants back to the contributor full unrestricted rights to the code they contributed. So, they can take the code they submitted (but only that code of course) and continue to use it in their proprietary applications if they would like--they have a license to use it outside the GPL.
Linus on documenting patch provenance Posted May 23, 2004 16:44 UTC (Sun) by corbet (editor, #1) [Link] I disagree; tracking the source of code submissions has little to do with copyright assignment. They are two separate issues. The kernel project has made a deliberate decision that contributors keep their copyright on their work; among other things, this approach ensures that nobody will ever attempt to force a different license on the kernel.Whether you ask for assignment or not, you still want to be sure that the contributor has the right to contribute the code--and to be able to document that in the future. An assignment of copyright does not make that happen in some magic way.
Linus on documenting patch provenance Posted May 24, 2004 16:20 UTC (Mon) by JoeBuck (subscriber, #2330) [Link] Jon, you need to take a more detailed look at the FSF's process before you comment further. Find out exactly what the FSF requires from both the contributor and the contributor's employer, and you'll see more clearly the steps they take to make sure that the bases are covered. A legally binding contract is signed by three parties: the FSF, the contributor, and the contributor's employer. The contract does more than just assign copyright. It also has some pretty strong patent language (though the FSF has negotiated weaker language with some contributors, notably IBM). Linus could start with that procedure and adapt it to his desire that the contributor retain copyright. The contract would grant Linus (or some designated body) the right to distribute, and forbid the contributor from coming back later and impeding the distribution (by, say, asserting a patent claim).
Linus on documenting patch provenance Posted May 24, 2004 17:46 UTC (Mon) by josh_stern (guest, #4868) [Link] Pointing out the obvious...To assume that the entity that thecontributor describes as her current employer is the only other party that might have copyright claims on the contributed code is, at best, a fairly weak heuristic, while going for something much stronger than that is likely involve substantial detective work. Perhaps there is some close tie in between the FSF standard and legal precedents for what constitutes reasonable due diligence?? I'd be interested to hear Eben Moglen's commentary on that.
Linus on documenting patch provenance Posted May 25, 2004 0:21 UTC (Tue) by mbp (guest, #2737) [Link] Another problem with the FSF system is that (when last I looked) the contributor indemnified the FSF from some legal liabilities arising from the contribution.Much as I love the FSF, I am not going to personally stand between them and a psychopath like SCO. Would they hold me to it? Probably not. But the risk is there. Taking on a potentially unbounded legal liability is a heavy disincentive to signing the FSF assignment.
|
|||||||||||