Do any Open Source Licences require source history?
shkspr.mobi
shkspr.mobi
> 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.
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.
I don't think that's true of even a majority of projects. Apart from anything else, you would need to separate code that is redistributable and code that is not, and presumably scrub them from the history. On some VCS, that is not trivial at all. Also, the history is likely much less clean than you're making it out to be. The history of Main in trunk based development is likely to be a gigantic pile of nonsense in my experience.
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.
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.
> 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.)
You are not obliged to supply any intermediate files, media assets, manuals, or technical supports as part of the licensing, though you are not restricted from doing so(you absolutely can charge full prices for GPL’d software)
Building from source but cleansing it before release or supplying irrelevant intermediate files, even de-complied files as sources... to “protect valuable assets”, those had been tried and are generally considered license/copyright violations.
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.
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), 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?
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.
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.
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.
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.
This is correct. It is also hosted on an original BSD (the b as in berkeley) 0.1 with the RCE affected ftpd 0.1 that had issues with too long usernames and passwords.
Oh, it's also hosted via http and ftp only, in case anyone is wondering about security aspects of it.
I'm talking about the porcupine server, as it is how the source gets distributed... I mean, gpg signing is fine and all, but if transport can be MITM'ed there's no way to verify the gpg signatures.
Contacted the author like hundreds of times, offered to help, but not a single eff was given apparently.
Postfix is really a nightmare project from both the missing collaboration aspects and missing security aspects.
I wouldn't call them releases, but they aren't normal commits...
The idea that all my work must be FOSS is somebody else's ideal, and one that has kept a lot of people I know from getting paid. Meanwhile, plenty of code, probably most running your world, is purely in the dark and definitely not open source.
Whatever you think about "license proliferation", that's like, your opinion. What world are you from that I can't have my own license for my own work? What kind of lemmings notion is it that I should only use a well known, open source license, especially a license that explicitly gives my work away uncompensated to random people on the internet?
You are so brainwashed with slogan terminology that you think Open Source has exactly one meaning, and that meaning is not even that the source code is open? Jesus, this forum is retarding sometimes. FOH with yr downvotes.
Edit, furthermore, I have dozens of totally FOSS code projects out there, downloaded millions of time per month. Is your business 100% open source, down to how to track your users? Stop telling people what they should do out here.
No, that's "visible source" or "source available". Read the Open Source Definition: https://opensource.org/osd
It even addresses your misconception right up front: "Open source doesn't just mean access to the source code."
> The idea that all my work must be FOSS is somebody else's ideal, and one that has kept a lot of people I know from getting paid.
You can get paid even if everything you build is FOSS. Look at Red Hat.
> Whatever you think about "license proliferation", that's like, your opinion. What world are you from that I can't have my own license for my own work? What kind of lemmings notion is it that I should only use a well known, open source license, especially a license that explicitly gives my work away uncompensated to random people on the internet?
Even if your bespoke license were open source, there's a very good chance that it would be incompatible with other licenses like the GPL, thus creating more ZFS-on-Linux sort of problems.
FOSS is also written F/OSS. It reflects that the common meaning of open source and the less common meaning of free software are almost identical. GNU says "...we know of only a few cases of source code that is open source but not free. In principle it could happen that some free programs are rejected as open source, but we don't know if that has ever happened."[1]
Source available is an unambiguous and more descriptive name for the kind of software that matters to you. Nobody can force you to call it that. But don't expect other people to change their definition of open source.
That says nothing about their ideals. Microsoft coined shared source the same year Steve Ballmer called Linux a cancer.[2][3]
[1] https://www.gnu.org/philosophy/categories.html.en
[2] https://en.wikipedia.org/wiki/Shared_Source_Initiative
[3] https://web.archive.org/web/20011108013601/http://www.suntim...
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.
To me, the OSS movement seems to be split between a minority of extreme idealism (Richard Stallman's position on the importance of software Freedom), and a majority of mostly big corporate pragmatists, which have realized that is far more lucrative to share the burden of developing common infrastructure between themselves than the previous status quo; and who greatly dislike anyone who tries to co-opt the OSS movement into something which does not serve this purpose. There is also a 3rd camp of companies that want to sell proprietary software, but who have noticed that open source variants of their software are a better marketing strategy than the shareware and freeware of old.
I believe that this third group is the biggest annoyance to both of the traditional OSS communities, but also the only ones who can actually make money by selling software whe also showing users exactly what code they are actually running.
You know what replaces open source? Trusted source. Not the source code, but the source of the code. I will gladly use code by somebody I trust, without looking, because ultimately I can't read every line, and nobody who preaches open source actually does read every line.
If you preach open source, or FOSS, but don't read and understand every line of code you use, you are a hypocrite.