In the case of open source software development, where contributions build on previous work I would find it more sensible for each copyright holder to hold copyrights on the diffs/deltas he/she contributed, instead of copyrights on files. Unless a contributor created a file, the contribution is a modification.

AFAIK, in projects with no CLAs, like the Linux kernel, copyright for contributions from different sources is still handled on a per file basis.

Implementing this concept means licensing would have to be integrated into Git/Mercurial/Bazar/Fossil/SVN, and at first it would be more complicated than adding a commented header with the license to each file.

What are the reasons (legal, technical, political, customary or otherwise) software licenses are applied to files instead of to diffs/deltas, especially now that version control systems are in wide spread use? Or is this a novel idea?

Note 1: Obviously the question does not apply in cases where there are Contributors Licence Agreements, and does not apply to non-FLOS Software.

Note 2: I mistakenly asked this on Stackoverflow and since instead of being moved here it was closed, I am asking this question here.

Note 3: A diff can be any of the following and more: a change to a single file, changes to multiple files, new files, any combination of the previous.

Note 4: The proposal mainly targets 2 situations:

  1. Discouraging creation of copylefted forks of copyfree projects for the sole reason of copylefting, accomplished by maintaining both copyleft and copyfree contributions in the same source tree, and filtering based on license.
  2. Enable license switching with the approval of all people necessary without anyone extra (e.g.: What if Linus would change his mind and would want to switch the license for Linux from GPLv2 to GPLv2+. Who would he have to track down and ask permission from. Must he ask permission from those whose contributions were discarded?)
  • How would you go about applying a different license to your contribution to a FLOSS file? Would you propose having a file with a dozen different licenses?
    – Jaydee
    Jan 30 '15 at 15:41
  • 2
    This looks like a legal question, which would be off-topic. Also, it's highly speculative, and depends on legal system.
    – sleske
    Jan 30 '15 at 15:51
  • 3
    This looks like a legal question.
    – sleske
    Jan 30 '15 at 15:52
  • 1
    @sleske: This question is not asking for specific legal assistance, it is asking about a basis of software licensing. "Software licensing" is specifically on topic. Jan 30 '15 at 16:01
  • 1
    @Jaydee: Indeed, the same way a multiple file project can have parts under GPL, MIT, BSD, Apache (and the harshest -GPL- determines the overall license of the project) so would files have parts under multiple licenses. The difference is that after someone contributes a GPL diff (without the need to fork the project) someone else can still contribute an UNRELATED diff under MIT in the SAME FILE. Otherwise either the project becomes GPL overall or GPL contributions must be rejected and banished to a fork in order to maintain overall copyfree licensing for the project.
    – alexvoda
    Jan 30 '15 at 17:08

It is mainly for practical reasons that copyright protection is applied on the level of files and not on change-sets.

First of all, most of the copyright law and the ideas encased in it stem from an era far before electronic copies existed. In those days there was no effective mechanism to make changes to a copyrighted work and only distribute those changes. What was possible is that person B took the work from person A, made some changes to it and distributed the changed version. So, copyright law was written to regulate those kinds of processes.

In addition, many copyright laws impose some minimum amount of originality to the change before the modified version becomes eligible for copyright on its own.

As a result, we now have the following situation:

  • A single contribution may not be substantive/original enough to qualify for copyright protection (just renaming a variable may not qualify)
  • If the single contribution is substantive/original enough for copyright protection, then the result of applying the contribution is considered a distinct work for copyright protection, separate from the original work.
  • If a single person makes several small contributions, each of which is not eligible for copyright protection on its own, it is still possible (and even likely) that the final product contains enough material from that one person to give that person a claim to the copyright on that material.

With that in mind, your proposal has the following practical problems:

  • As the result of applying all the contributions is considered a copyrightable work under copyright law, allowing different copyright licenses for the different contributions (presuming those contributions are each significant enough) means that each token in a file could be subject to a different copyright license. It will be almost impossible to tell what you will be allowed to do.

  • As many individual contributions are likely to be too insignificant to be copyrightable in their own right, depending on the jurisdiction, it is impossible to attach license terms to those contributions.

  • Taken together, several small contributions from one person give that person a claim to the copyright on the resulting file. The license terms will be those of the original copyright license, because the individual contributions were too small to dictate other terms.
  • Great answer. You raise a good point about the individual and combined substantialness of contributions. Your answer together with answers gathered from @amon s comments show that the idea is actually incompatible with how copyright itself works. Therefore, further pursuit of this idea is useless because applying it in a world with copyright is impossible and pointless in a world without copyright. As such, I will mark this as the accepted answer and try to sum everything up in a note to my question.
    – alexvoda
    Feb 1 '15 at 23:58
  • Also, thank you for bringing up the correct term to use ("change-set") rather than using the terms "diff" or "delta" that I used.
    – alexvoda
    Feb 2 '15 at 0:02

It's because the modifications are legally considered a derivative work, because they build on and depend on the work already done. This protects the original authors against someone adding a popular new feature that builds on their work, but then making that feature closed source. If authors wish to allow closed-source extensions to their software, they can make that explicit, such as how the linux kernel allows closed source modules, but requires them to be marked as "tainted."

  • Some licenses (e.g. BSD) do not require derivative works to be open-sourced but only require attribution. Therefore, a feature can be closed-source.
    – amon
    Jan 30 '15 at 16:14
  • True. That's another way to explicitly allow closed-source derivative works. Jan 30 '15 at 16:18
  • Copyfree licenses allow derivatives to use other licenses. Assume I make project A licensed under MIT. Person X makes contributions A1 under MIT, A2 under BSD, A3 under GPL.(there is no rule that 1 contributor must use only 1 license). If I want to release the project and maintain copyfree licensing I would have to eliminate contribution A3 from the release, otherwise the release becomes GPL. If A1, A2, A3 are new files, this is easy. If they are modifications to files this is very complicated.
    – alexvoda
    Jan 30 '15 at 16:33
  • 2
    Additionally, assume GPL contribution A3 modifies part of file F1. Afterwards person Y contributes change A4 to file F1. A4 DOES NOT depend on A3. How is A4 licensed? If A3 was rejected (person X must create a fork) A4 can have any license. If A3 slipped in, A4 will also be GPL, because the license applies to the file. Now if I want to release a copyfree version, I would have to eliminate both A3 and A4 even if A4 does not depend on A3. However if A4 was in file F2 there was no problem.
    – alexvoda
    Jan 30 '15 at 16:54
  • 1
    @alexvoda Completely correct. This sort of nonsense is exsctly why some of us thought the GPL was a Bad Idea when Stallman first announced it. Jan 31 '15 at 15:56

Probably because the end users are using your files, not your diffs, and licenses are supposed to be distributed along with your software (whether in source or binary or some other form). You don't distribute your software as a series of annotated diffs, do you?

There may also be a legal reason, but that's a question for a different website.

  • Actually end users are using the project as a whole. And the project itself may even be: a) subject to copyright by multiple authors and b) subject to multiple licenses depending on the components included.
    – alexvoda
    Jan 30 '15 at 16:04
  • What exactly do you mean by "using the project as a whole"?
    – Ixrec
    Jan 30 '15 at 16:14
  • End USERS usually either use a RELEASED binary (the project as a whole) or compile a RELEASED version of the project (Gentoo users). Potential developers can compile directly from the source tree. Therefore they interact with the VCS and can be informed about the applicable licenses. The license for any release (output from VCS) should be generated by the VCS based on the licenses of the diffs involved.
    – alexvoda
    Jan 30 '15 at 16:42
  • you are correct that "the project as a whole" is the wrong term to use. What I meant was releases. Releases (binary or source) are the output of a software project and therefore the output of the version control system since they are no longer managed by the same VCS (they may become inputs for a different project).
    – alexvoda
    Jan 30 '15 at 20:04

I think you are confusing licensing and copyright. Each contributor to a shared project without copyright assignment only owns the copyright over their own contributions, in other words copyright over each diff they produce. A contributor would only own the copyright over a whole file if nobody else contributed to that file. As a result, most files have shared copyright between multiple authors.

Now why do we need licenses? If a software is meant to be used by other people, it requires a license: the license states the terms under which other people may use the software. For example, you are not generally allowed to modify some software and publish your modifications. Even if you have access to the source of some software, you may not publish any enhancements you wrote. If we have a project where we want people to contribute, the whole project needs to be available under a license that allows this. And all contributions must also be provided under this license so that others may build upon these contributions as well.

It is not viable to have one project or one file contain code under multiple different licenses. For starters, many licenses assume they are applied on a per-file or per-project basis. Also, imagine a potential user or contributor trying to figure out whether they can use the software. It is not realistic to look through all previous contributions to check whether they can use, modify, and distribute a software. It is much simpler to state one project-wide license, and any contributions must also be provided under that license.

  • 1
    "As a result, most files have shared copyright between multiple authors." - Precisely, that is why in projects with no CLAs, changing the license of the project requires the approval of all contributors. But actually finding which contributions are still included and which were discarded is non-trivial. My proposal was that a VCS should track who has copyright over what.
    – alexvoda
    Jan 30 '15 at 16:18
  • 2
    "It is not viable to have one project or one file contain code under multiple different licenses." Any GPL licensed project that includes MIT or BSD licensed code is subject to multiple different licenses.
    – alexvoda
    Jan 30 '15 at 16:21
  • 1
    "many licenses assume they are applied on a per-file or per-project basis." True. Ultimately is this the answer I am looking for? "Because licenses are written assuming this"
    – alexvoda
    Jan 30 '15 at 16:23
  • 2
    Indeed MIT and BSD allow sublicensing, not relicensing. The MIT parts remain MIT licensed, The project as a whole abides by the harsher license(the GPL). Theoretically I could take a GPL project which contains MIT parts, strip out all the non-MIT parts, and do anything MIT-permitting to the MIT parts left. My proposal just applies this to a more granular level.
    – alexvoda
    Jan 30 '15 at 17:21
  • 2
    "then does that original author has a say in a copyright change? Probably yes." Answering this question most probably depends on weather APIs are copyrightable or not. AFAIK there is no consensus about this.
    – alexvoda
    Jan 30 '15 at 20:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.