|
|
Log in / Subscribe / Register

Copyleft-next and the kernel

Copyleft-next and the kernel

Posted Jul 14, 2021 10:32 UTC (Wed) by smoogen (subscriber, #97)
Parent article: Copyleft-next and the kernel

My main concern with the copyleft-next code is section 8:

```
8. Copyleft Sunset

The conditions in sections 3 through 5 no longer apply once fifteen
years have elapsed from the date of My first Distribution of My Work
under this License.
```

While fifteen years sounds like a long time, if Linus had put the kernel under this license in early 1992, then in 2008 the entire kernel would have gone in a 'weird' state because definitions of 'My Work' etc would be contested. 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.

```
"My Work" means the particular work of authorship I license to You
under this License.
```

while plain legal English may be too plain for a long living project of code covered by said code. [That said, I doubt in 1992 I thought I would be spending the next 30 years of my life working with Linux.. so having 15 years of it under BSD-like might have worked out ok.]


to post comments

Copyleft-next and the kernel

Posted Jul 14, 2021 13:58 UTC (Wed) by Paf (subscriber, #91811) [Link] (2 responses)

This is a pretty standard debate, I think, pretty similar to authorship itself - how much do you need to change/add before you can claim copyright in something of which you are not the originator?

There’s no simple answer.

Copyleft-next and the kernel

Posted Jul 14, 2021 20:10 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (1 responses)

Well, there is an answer, it's just not an answer that anyone wants to hear: "Go to court and the judge will tell you."

But as a rule of thumb, the threshold of originality is generally quite low. If you just fixed a typo, you probably can't claim copyright on the fix alone. If you (re)wrote or substantially refactored* a whole function, you probably can claim copyright on that.

* You might argue that refactoring should not be eligible for copyright protection because it makes no functional change to the software. This is incorrect. Copyright does not care at all about functionality, and "it's functional" is in fact an argument *against* copyright protection (e.g. you might not be able to copyright a "hello world" program, because there's usually only one reasonable way to write such a program). Copyright protects the creative expression of an idea or concept (but not the idea or concept itself); refactoring code to make it clearer or easier for a human to understand is definitely the right sort of work to merit copyright protection. The only thing that matters is scale: whether you refactored enough code and made enough changes to that code.

Copyleft-next and the kernel--originality

Posted Jul 21, 2021 5:04 UTC (Wed) by carORcdr (guest, #141301) [Link]

Originality is a constitutional requirement. Constitution of the United States, Art. I. sec. 8[8], 1 Stat. 10; Feist Publications, Inc. v. Rural Telephone Service Company, Inc., 499 US 340 (1991); The Trade-Mark Cases, 100 U.S. 82 (1879). Some minimal degree of creativity is requred. Feist Publications.

"Refactoring" is not reflected in the Law of the Land, but compilations and derivative works are. Pub. L. 94-553 [sed. 103], 90 Stat. 2541, 2544 (1976). It is only that portion of the 'refactoring' that is original to the author. Feist.

Copyleft-next and the kernel

Posted Jul 14, 2021 14:29 UTC (Wed) by rfontana (subscriber, #52677) [Link] (4 responses)

"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.

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

Copyleft-next and the kernel

Posted Jul 14, 2021 21:13 UTC (Wed) by josh (subscriber, #17465) [Link] (2 responses)

I don't think copyright should last as long as it does. As long as it *does* last that long, though, I think copyleft should last just as long.

Copyleft-next and the kernel

Posted Jul 16, 2021 21:56 UTC (Fri) by marcH (subscriber, #57642) [Link] (1 responses)

Come on Josh, how come you never think about your future grand-grand-children when you write code? :-)

Copyleft-next and the kernel

Posted Jul 21, 2021 7:27 UTC (Wed) by Wol (subscriber, #4433) [Link]

Copyright should be short, and transition to trademark when it expires, if it's still of value. So Disney could protect Mickey with trademarks, and the rest of us get to access all that stuff that's old and worthless after 10 years (I don't know the figure, but the commercial value of most copyrights after that long is about £0.00).

Or just create a "register of extended copyrights" which it is the copyright holder's duty to keep up-to-date. If you don't keep your contact details up-to-date every, say, 5 years so that people can contact you for permission, it falls off the register and can't be put back.

Imho for personal copyrights at least term should be the greater of 25 years, life of author, or 120th birthday of author. That's not really a major change from what it is now. Commercial copyright is a bit more tricky ...

Cheers,
Wol


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds