
Do any Open Source Licences require source history? - edent
https://shkspr.mobi/blog/2020/08/do-any-open-source-licences-require-source-history/
======
mehrdadn
Layman here, but this seems pretty easy to answer for GPL at least because it
defines [1] what "source code" means (with a rather brilliant definition, I
might add):

> The "source code" for a work means the preferred form of the work for making
> modifications to it.

I expect it would be tough to argue that the preferred form of a work to
modify is its history rather than its present form.

[1]
[https://www.gnu.org/licenses/gpl-3.0.txt](https://www.gnu.org/licenses/gpl-3.0.txt)

~~~
gizmo686
My preferred form of a work would be the a VCS repository with the complete
history (assuming it is a familiar VCS like git. If you are using some obscure
VCS that I can't get to work, I'd settle for a simple source dump).

Almost every project I have worked on has went out of its way to maintain a
good history. Wheather it is by cleaning up commits before merging into a main
branch; making sure history gets copied when a reorganization moves a
significant amount of files to a different repository, or making sure history
gets copied when an entire repository moves over to a new VCS.

~~~
mehrdadn
The quote was that the source code is the _form of the program_ you would
prefer to _modify_ , not the _information_ you would prefer to _have
available_. These are different things.

------
ximm
This reminds me of a post by Steve Klabnik:
[https://steveklabnik.com/writing/what-comes-after-open-
sourc...](https://steveklabnik.com/writing/what-comes-after-open-source)

In that he argues that open source is less about publishing the code and more
about a culture of developing in the open, with a public source repository and
public issue tracker.

------
Latty
I mean, each time you distribute the software you are bound to the license
terms for that version, so if you use the same license through time, you have
to give that much history.

Beyond that, it clearly becomes very murky, especially when it comes to git.
Is squashing some commits suddenly against the license? Do I have to commit
every time I type a character? There is no obvious smallest unit except "the
commit the developer decides on", which could then be everything since the
last release, resulting in the status quo.

I guess there could be a license where if you changed to that license, it
required the history, but it would seem a bit pointless, as inherently at that
point the person choosing the license could just choose a different one.

~~~
akkartik
Do similar questions come up even for the current snapshot? Are you required
to provide comments? Meaningful type and variable names?

~~~
eredengrin
Not a lawyer, but I did work for a short period for a company that was
distributing a modified linux kernel and therefore had to release the source.
In my time there, there were a lot of discussions (some involving lawyers)
about whether (and how) we could reasonably obfuscate the source before
releasing it. Not sure how those conversations ended since I left before they
were done, but it seems it's not clear cut at this point.

~~~
jlokier
I struggle to imagine how this definition in the Linux kernel's license:

> The source code for a work means the preferred form of the work for making
> modifications to it.

can be seen as "not clear cut" with regard to whether obfuscated source code
counts.

It plainly rules out obfuscation.

(Unless you genuinely prefer editing the obfuscated version. Which you
provably don't if obfuscation is done just for release.)

~~~
eredengrin
What is preventing a company from hiring a developer or two for very cheap to
"work" on the obfuscated code, but not do any real work (or better yet, just
bundle it into an existing job description of a qa member or a dev on some
other team or something)? How would you prove in court that the devs "working"
on the obfuscated version weren't the ones doing the work? It brings into
question which version is actually preferred over the other, and how do you
answer that? Based off number of commits or changes on the branches?
Obfuscated version could easily be gamed to have more commits, and given that
it's obfuscated, it might have even more individual changes just by default. I
imagine there are some companies that think these questions are worth
pondering.

------
not2b
What would the definition of "source history" be? The git database? If I do a
rebase would I be violating the license? After all, I am collapsing the
history, getting rid of failed ideas no one else needs to see.

------
powersnail
My basic understanding is that license (usually?) applies to just the code.

There is no concept of "history" or "snapshot" pertaining to the code itself.
Such constructs only exist with regard to the process of development, about
which the code license does not care. Otherwise, every keystroke must be
recorded and published to ensure compliance, at which point, the license is
ridiculous and unenforceable.

------
kemitchell
I am not aware of any common "open source" license that requires distribution
of comprehensive source code revision history or version-control information.

A number of licenses, including the GPLs, require those who make changes to
licensed software to note that changes have been made when distributing their
changes to others. A few also require distribution of changed versions in the
form of the original or "official" distribution plus patch files. Have a look
at the Artistic Licenses from the Perl community. And note that "permissive"
(non-copyleft) licenses don't require sharing source at all.

Nonetheless, some licenses assume that development-related information will be
available, required or not, for the purpose of other license provisions. For
example, Apache 2.0 determines which patents get licensed based on who is
contributing code that implicates a patent, alone or in combination with the
state of the project prior to their offer of a new contribution

Even with comprehensive revision-control and licensing information, it's not
always practical to determine whether a patent is covered. The Apache
Foundation systematically compiles and archives contribution-related
information, by institutional policy. Other users of Apache's license, like
startups, don't necessarily follow suit. Ditto with other licenses following
Apache's approach to patent scope, which is now quite common in
"enterprise"-oriented license terms.

Even my own, very strong copyleft Parity license
([https://paritylicense.com](https://paritylicense.com)), which comes the
closest to requiring "development in the open" of any terms I've seen, does
not require unbroken development history or distribution of history data in
any particular form, like a Git repository or an unbroken chain of patch
files. My first thought is that requiring open work process would be
difficult, especially without tying the requirement to specific tools or
platforms---GitHub, Git---that will surely face obsolescence in time. But my
second thought is that licenses have already adequately solved an analogous
problem with success. A license could require that source code changes be made
available not only in the preferred form for making further changes, but also
in the preferred form for analysis of prior changes already made, for code
copyright provenance verification, regression testing, incorporation into the
"official version", development metrics calculation, or the like.

I'm not sure I see a concrete use case requiring those kinds of terms. Nice to
have, sure. But in what circumstance essential?

------
purpleidea
Assuming it's still the case, Red Hat used to release all their RHEL-kernel
specific changes as individual patches, but apparently it made this too easy
for Oracle to copy and cherry-pick in the ones they wanted, so the Red Hat
released source code became a big giant squished patch.

They felt it still complied with GPLv2, and TBH, I don't think that it
doesn't. Not necessarily in the spirit of the license, but a necessary
solution against Oracle in their minds.

GPLv3 defines it differently, but I doubt you could convince anyone of this in
court. I think getting the source in any form would be a good enough start for
most of the companies flaunting the GPL.

------
smcphile
> My question to you, gentle reader – are there any licences which compel the
> distribution or publication of the development history?

No, other than that any given project has to give proper credit to code used
from other projects / copyright holders.

My understanding of why this is so is the following: A free software or open
source software licence is based on copyright law. As such, it restricts what
users can do with the source code, but it never restricts what the copyright
holders can do with the software (assuming all the copyright holders
collectively agree).

A user can never (theoretically at least, there may be a few edge cases) sue
the copyright holders for anything, because there’s no warranty. No warranty
on the code source history (or anything else). So code source history is
always optional.

~~~
coolness
This is exactly what most people in this thread are missing. The copyright
holder, i.e the creator of the code is never obligated to do anything by the
licence he chooses to release with. The licence applied to users of the
copyright owners work.

~~~
throwaway936482
That's not true though. Open source licenses (as defined by the OSI) impose
specific obligations upon me as creator - to distribute the source code for
"no more than a reasonable reproduction cost" to users, allow users to modify
it, and to redistribute it for free if it is bundled with other software, and
not to discriminate against persons, groups or fields of endeavour in who can
use it.

~~~
smcphile
No, open source licenses impose no obligations on the copyright holder for
their own code. For example, if the copyright holder releases their own code
under a GPL licence, no law prevents them from also releasing a modified or
unmodified version under a proprietary licence. This is allowed by law, but
the proprietary version doesn’t of course negate the rights already given to
those who received the GPL version.

If a project has many contributors (copyright holders), they would all have to
agree to a license change, so in practice something like the Linux kernel is
very unlikely to ever change to a proprietary licence, but it’s theoretically
possible.

The copyright holders are never bound by the terms of a user licence.

------
sverhagen
Isn't the requirement to disclose source with a system so that you can make
changes (bug fixes and such) without being locked into a vendor? Current
source offers that. Other than that licenses typically stipulate that there
are no warranties and no support. I see source history more as a support tool
(to understand design decisions) than as the "absolute" ability to fix a bug.
(This is not and answer to the question, I realize.)

------
tleb_
Assuming a GPLv3-licensed project, would one be in his rights to ask for a
previous "Corresponding Source" because he uses a previously released "object
code"?

~~~
tsimionescu
At least in the company I work for, the understanding is that we have to make
available the source code that corresponds to0 the binaries that we are
distributing.

So, if I am distributing Linux 2.0.12, I have to also make the source code of
Linux 2.0.12 available to my customers. The sources for Linux 5 (or Linux
2.0.13) are not useful.

------
walterbell
With the advent of reproducible builds, it can also be useful to have a
specification of the build environment needed to reproduce a binary from a
given source code snapshot.

------
gramakri
AFAIK, postfix has no history. Only releases.

~~~
yjftsjthsd-h
Maybe?
[https://github.com/vdukhovni/postfix/commits/master](https://github.com/vdukhovni/postfix/commits/master)

I wouldn't call them releases, but they aren't normal commits...

~~~
gramakri
I think it's just putting releases in a git repo

------
angel_j
The MIT license is so simple, just add/delete to make your own. My bespoke
license is free and open source for the user, but restricts them using it for
or on behalf of another person.

~~~
josephcsible
That sounds like it's not open source. Also, license proliferation is a bad
thing and you really shouldn't encourage it.

~~~
throwaway936482
Can I ask why it is that the "foss community" is so hell bent on restricting
the freedom of creators to call their software open source if the source is
open, or choose licenses that might help them actually support themselves
financially? As far as I can tell the "freedom" pushed by Foss evangelists
only goes one way - to benefit often corporate consumers. I genuinely don't
think I've ever seen a "community" that is so intent on policing language and
action than that which exists around Foss.

~~~
tsimionescu
I think the FOSS community cares a lot about the freedom of the end-user, not
so much about the freedom of original creators. That is, the freedom of
everyone to become a creator, not the freedom of one particular creator to
control their creation or profit from it in some way. This applies both to the
GPL camp, which cares about the end-user of the binary; as well as the BSD/MIT
camp, which cares about the end-user of the source.

Hence, their dislike of any kind of licenses which impose restrictions on
consumers of the code/binary.

I'm not saying I agree, just presenting what I believe is the thinking behind
this kind of policing.

~~~
throwaway936482
I think my issue is that a nobleish idea that supported the freedom of
everyone to be a creator has morphed into something (an ideology, a secular
religion) that demands that creators not be able to make a living off their
creation even if (or especially if) they are providing tooling for
corporations that give nothing, or at least very little proportionally, back.

~~~
josephcsible
If you dual-license your work under the AGPL and a paid non-copyleft license,
then your product will be 100% FOSS, and you'll still be able to make a living
from it instead of the Amazons of the world selling your product and giving
nothing back.

~~~
tsimionescu
That's what Mongo thought as well, and it turned out not to be true in their
case (well, s/make a living/turn the profit your investors expect/g).

