Copyleft-next and the kernel [LWN.net]

Copyleft-next and the kernel

Posted Jul 14, 2021 14:29 UTC (Wed) by rfontana (subscriber, #52677)
In reply to: Copyleft-next and the kernel by smoogen
Parent article: Copyleft-next and the kernel

"Is someones patches in 2007 now also 'BSDish?' because the first distribution was 15 years before then? Or does 'My Work' mean every subsection written by different authors so end up with different lines aging out on different days? Or is 'My Work' each release of the kernel."

Of those 3 possibilities, the answer ought to be the second I think --- for a project consisting of multiple copyleft-next-licensed contributions over a period of time, the project consists of multiple "My Work"s, each transitioning from copyleft to non-copyleft on a different schedule. I would argue this is actually not different in the GPL (where, for a project like the kernel, there are multiple "Programs" with different initiation dates and different licensors), except that the transition would be dependent on the expiration of the vastly lengthier statutory term of copyright.

to post comments

Copyleft-next and the kernel

Posted Jul 14, 2021 18:43 UTC (Wed) by mattdm (subscriber, #18) [Link] (1 responses)

As a non-legally person, that wasn't apparent to me at all, even though on reflection it makes more sense than my naïve assumption. Perhaps this could be made more obvious in a future version of the license?

Copyleft-next and the kernel

Posted Jul 14, 2021 20:05 UTC (Wed) by rfontana (subscriber, #52677) [Link]

Yes, I think it should be made clearer. The underlying concept is pretty simple.

Copyleft-next and the kernel

Posted Jul 14, 2021 21:21 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

I don't think there's much practical difference between the second and third option. The logical interpretation of the license is that the 15 year wait for code to be available starts as soon as it's released, and re-releasing it doesn't somehow reset the waiting time*. In that case, you can always go back to the earliest release that has the code you want to copy as a basis for copying it. If the license applies to the software as a whole, it would also apply to each individual part, so you would be able to take whatever snippet you want. Similarly, if the license applies to each part, it should also apply to the whole.

As a practical matter, I think this kind of thing has real dangers that would make me leery of reusing the code from a project under this license. Yes, you're in no trouble if you copy the code verbatim. But what happens if there's a bug in the code you copied, and your patch for the bug happens to be the same as the way the original project fixed it and that code is still under copyleft? Your code is now a duplicate of copylefted code, and it doesn't matter legally if you arrived at the solution independently.

*IANAL, but I think that trying to reset the clock this way would be legally dicey even if that's what the license purported to do.

Copyleft-next and the kernel

Posted Jul 14, 2021 23:33 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

> But what happens if there's a bug in the code you copied, and your patch for the bug happens to be the same as the way the original project fixed it and that code is still under copyleft? Your code is now a duplicate of copylefted code, and it doesn't matter legally if you arrived at the solution independently.

If you can convince a judge that your solution really was independent, and you didn't look at their solution, then it's unlikely to be copyright infringement under US law, because copyright infringement only happens when you do one of the things listed in 17 USC 106[1] without permission. "I came up with it independently" is not any one of those things. Of course, good luck proving that unless you're doing some kind of clean-room reimplementation. For larger and more complicated changes, you might be able to use intermediate Git commits as evidence of originality, so hopefully you're not one of those git squash people.

OTOH given that you really did come up with it independently, you may be able to argue that the similarity between your code and theirs is purely functional, and not subject to copyright protection in the first place.[2] This is especially likely to be the case for simple one-line bug fixes, where there's only one or two reasonable ways to fix it (e.g. "this loop is off by one, so switch the <= to <, or add/subtract one somewhere"). You might also raise a fair use, de minimis, or merger/scènes à faire defense, depending on the circumstances.

[1]: https://www.law.cornell.edu/uscode/text/17/106
[2]: See 17 USC 102(b): https://www.law.cornell.edu/uscode/text/17/102