Do any Open Source Licences require source history?(shkspr.mobi)
shkspr.mobi
Do any Open Source Licences require source history?
https://shkspr.mobi/blog/2020/08/do-any-open-source-licences-require-source-history/
55 comments
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.
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.
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.
> Almost every project I have worked on has went out of its way to maintain a good history.
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.
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.
The GPL doesn't require history, but that doesn't answer the question of if there is another license that does.
That means, IMHO, that you can't only distribute generated Assembly code instead of your original C or whatever. Because while technically "source code" (not a binary!), it is not the form in which development actually takes place.
I believe that's the intent of the clause. It's pretty clever.
When I modify a program, I often refer to its history. So my preferred form would be something like a git repository, rather than just a tarball.
It's the form you would prefer to modify, not the information you would prefer to have available. I'd prefer to have all the information in the world available, but that doesn't make everything the source code.
This reminds me of a post by Steve Klabnik: https://steveklabnik.com/writing/what-comes-after-open-sourc...
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.
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.
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.
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.
Do similar questions come up even for the current snapshot? Are you required to provide comments? Meaningful type and variable names?
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.
dataflow's comment (https://news.ycombinator.com/item?id=24019778#24025779) seems to answer this, and https://opensource.stackexchange.com/questions/5759/code-obf... elaborates: FOSS licenses require distributing the form you use to make modifications to your program. To do anything else opens one up to legal liability.
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.)
> 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.)
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.
I believe the gist of GPL is you supply the source code that produced the binary object through your compilation processes to whoever received the binary as you were licensed it as part of the sale or distribution.
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.
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.
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.
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.
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.
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), 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?
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?
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.
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.
[deleted]
> 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.
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.
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.
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.
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.
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.
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.)
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"?
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.
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.
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.
[deleted]
AFAIK, postfix has no history. Only releases.
> AFAIK, postfix has no history. Only releases.
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.
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.
Is https://github.com/vdukhovni/postfix/commits/master not official?
Nope, ftp.porcupine.org is the only distribution source, from there it gets pushed to mirrors, from there people maintain the history manually.
Postfix is really a nightmare project from both the missing collaboration aspects and missing security aspects.
Postfix is really a nightmare project from both the missing collaboration aspects and missing security aspects.
Maybe? https://github.com/vdukhovni/postfix/commits/master
I wouldn't call them releases, but they aren't normal commits...
I wouldn't call them releases, but they aren't normal commits...
[deleted]
I think it's just putting releases in a git repo
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.
That sounds like it's not open source. Also, license proliferation is a bad thing and you really shouldn't encourage it.
Open source means you can read the source.
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.
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.
> Open source means you can read the source.
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.
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.
This needs more downvotes.
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.
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.
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.
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.
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.
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).
Sure, that is a valid position, and I mostly believe the same that you do.
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.
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.
Open source has a specific common meaning. Other ideas have other common names like source available.
It means you can read the source. It doesn't mean it has to be free. That would be FOSS. And nothing has more convoluted multi-meanings than FREE, so your argument about "common meaning" is dead wrong. Also, trying to enforce universal meaning, like enforcing universal ideals, is patently retarding. FOH!
Free software has 2 common meanings. That says nothing about open source.
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...
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...
Open Source really became a religion, and every acolyte believes in their heart that non-FOSS is evil. Total newb flavored koolaid. It's not like I am advocating against FOSS, or open source, I am simply drawing a line where it matters and where it doesn't, for me.
Please, do tell, how long have you been writing "open source" and how much of your source is really open, and how much of that open source has anybody read?
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.
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.
You know why this is better than your name brand Open Source license? Because this forces people to be closer to their software, to share in the learning of using Open Source software. What good is MIT to give somebody the right to MISUSE my software on somebody? Because they can make a buck? My license prevents abuse directly, and automatically. You can't use this spell on somebody else.
> 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