Fortran software project licensing considerations

[zbeekman]

While I feel that there is no one-size-fits-all choice for an appropriate license for new Fortran software projects, and trying to reach a consensus and trying to make a specific recommendation is beyond the scope of Fortran-FOSS-Programmers/Best_Practices, I think that a discussion of various licenses, their pros and cons, and implications for Fortran and scientific computing projects would be useful. This is the appropriate location to discuss such considerations, to be included in a "licensing discussion" document. The goals of this document should be (open for further discussion here):

1. Be as neutral as possible; we all prefer certain licensing schemes but let's try to discuss the different licenses as factually as possible
2. Describe open source software licenses in plain english
3. Enumerate their properties and requirements
4. Discuss theoretical and practical implications for choosing a given license
5. Discuss their pros and cons in different contexts
6. Let me know if there are other topics you want to see included and I'll add them here

Here is an incomplete list of licenses I think we should cover/discuss:

1. MIT
2. GPL
3. LGPL
4. BSD2
5. BSD3
6. CC (probably shouldn't be used for code)
7. The "unlicense"
8. I'm sure there are others I am forgetting.

See the now locked #7 for some previous discussion history.

[cmacmackin]

Some potentially useful resources are listed below. I don't mean to over-promote GNU at the expense of other sources, it's just that I was reading some of their documents the other day and thus have some familiarity with them.

• GNU list of free licenses: listing of licenses classified as free by the FSF, as well as information on their compatibility with the GPL
• GNU license selection advice: their views on what license should be used in what circumstances. Various other documents on the website may be of interest.
• Why you should use a BSD license
• Comparison of FOSS licenses: a table on Wikipedia
• Open Source Initiative
• FSF Licensing Information

[zbeekman]

I also really like the resource @milancurcic linked to in #7: http://tldrlegal.com
Also, github recommends http://choosealicense.com to help figure out how to license your project.

I think that the licensing discussion page definitely needs a resources section.

[cmacmackin]

Just copying over a few of my old comments...

---

I'm more evangelical about open source that @rouson and tend to favour the GPL for software. My logic is that I am donating my time to produce software with the intent that it be open source. I don't want someone to be able to privatize the public good which I have helped produced and hence I opt for a strong copyleft license. . . I suppose the LGPL could also be a compromise between GPL and BSD.

I know that some companies shy away from using GPL software even when the license wouldn't pose any problems for them (e.g. if they were only going to use modified versions of the software internally), but if that's the case then it's their own fault and ignorance and I can't say I have much sympathy.

Anyway, just my personal view. It's not like I'll refuse to work on a project if it uses a BSD license.

---

Not meaning to sound whiny at my views generally being panned, but I'm genuinely curious. Why do people have a problem using something under the LGPL or GPL with the linking exception (which I'll take as synonymous with LGPL when writing this comment)? Technically anything compiled with GCC is using code licensed under the GPL with the linking exception, in the form of glibc. LGPL only restricts people if they want to change the the actual code licensed under it. It doesn't restrict people from using the libraries as is with proprietary software. Seeing as the argument against LGPL is that it hurts something being adopted as a standard, we don't really want a plethora of subtly altered versions of a library out there anyway. In any case, even the strong GPL only restricts people if they want to distribute modified versions of your code. There is nothing to stop them using modified versions internally, as far as I'm aware.

---

On that note, I just thought I'd add one last argument for the GPL before inevitably giving in: Why you shouldn't use the Lesser GPL for your next library. In particular, it addresses the point about attracting more users at the end. My preference would be to follow their advice and license libraries for which there are competitors under the LGPL and all others under GPL.

---

. . . the LGPL does not require the whole project to be released in source form--only the library modules which are under the LGPL and anything directly derived from them. Code which simply calls said libraries can be licensed in whatever manner its developer wishes. At least, that is my understanding from browsing the license text, although I admit that I could have misunderstood it. I'm not quite sure I follow your point about code compiled with GCC. The point I was making is that it is legal to link LGPL code (or something similarly licensed) to non-(L)GPL code. GCC is simply one of the most prominent cases of this--there are other bits of software with similar provisions.

[zbeekman]

Added a place to formalize this discussion: https://github.com/Fortran-FOSS-Programmers/Best_Practices/blob/master/License-considerations.md

Please note, I would like this document to be as factual and unbiased as possible.

[LadaF]

I am not a lawyer, but I see the problem with the linking clause in GPL as
the following. It can be used for LGIBC and other runtime libraries,
because the programmer who uses them is not creating a derivative work
based on these libraries. He is writing in a documented (and standardized)
programming language and then some appropriate runtime library is linked.

However, if one creates a library with enables Fortran programmers use some
datastructures or algorithms, their programs will be derivative works based
on the library. In this case their code will have to be licensed using GPL.

2016-01-17 17:52 GMT+00:00 Izaak Beekman notifications@github.com:

Added a place to formalize this discussion:
https://github.com/Fortran-FOSS-Programmers/Best_Practices/blob/master/License-considerations.md

Please note, I would like this document to be as factual and unbiased as
possible.

—
Reply to this email directly or view it on GitHub
#8 (comment)
.

[nncarlson]

I don't work in a corporate environment but I can offer some insight into the corporate view of FOSS software, particularly GPL, based on recent first hand dealings with counsel from a major US company. The software in question was GPL licensed and technically this should have been fully adequate for their intended purposes. While they planned to extend the software, conceivably with proprietary information at some point, they had no intent to ever distribute the modified software outside of the company -- it was for internal use only. Nevertheless they would not use the software under the GPL, and we made arrangements to provide it under a different license. Their explanation was this. It is nearly impossible to completely control a code once it is brought into a large company. Many employees will have access to it, and it is just a matter of time before one of them mistakenly and innocently shares it (a binary) with a collaborator outside the company. At that point the GPL kicks in, raising the specter of the company being forced to expose proprietary information. No lawyer worth his/her salt is going to expose their company to that kind of risk. I can appreciate their point of view.

This particular company had given prior serious thought to FOSS and had ranked them in terms of risk. BSD, MIT, and Apache were at the top of the list, as I recall, with a thumbs up. GPL and LGPL were at the bottom and could be used only in certain contexts (e.g., the binary executables in a typical Linux installation). GPL was off-limits if it involved working with source. The software in question relies on a bunch of third party libraries, several of which were LGPL licensed and distributed in source form with the software. Even this made them very nervous. Those libraries had to be linked dynamically, and even then the counsel (rightly or wrongly) said it was arguable whether that was enough to render the rest of the code not a derivative work.

Since then we have decided to release the software under the BSD license. This is making collaboration with external partners much easier, as well as making us more attractive to collaborate with.

[zbeekman]

@nncarlson Thank you for sharing your experience! In a perfect world, the theory and practice of OSS licensing would be the same, but I can understand corporations trepidation that an errant employee might land them in hot water.

[szaghi]

@nncarlson thank you very much! I agree with Zaak, unfortunately we live in a real world, ideal is not here.

[cmacmackin]

@LadaF The way the exception is written for glibc may make that the case. However, in the case of GNU Classpath, it is not. In their own words:

Classpath is distributed under the terms of the GNU General Public License with the following clarification and special exception.

Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obliged to do so. If you do not wish to do so, delete this exception statement from your version.

@nncarlson Not that this will change whether or not a corporation doesn't wish to use LGPL software, but it isn't strictly true that the libraries have to be linked dynamically. If you look at the license, it does outline conditions in which libraries can be linked statically. Basically it just has to be possible to strip out the statically linked library and re-link with a different version. I'm not claiming that this alters your fundamental point, just making sure that people are aware what the licenses actually require.

[victorsndvg]

Hello all,

I have to say that I'm agree with @cmacmackin . I prefer GPL and LGPL licenses, but I'm not against any other kind of licenses and I'm open to work with other licenses.

In general, I like to think that I develop open source code to be always open and used in open projects.

[Comment update] I'm not against the use of any of my open source code in a privative project, and, of course is not forbidden. The only restricted thing is the relationship between both projects.

I think that free licenses are made to protect the author and not any "corporation that could potentially use the code". For me, the "author point of view" is the right side while choosing an open license. Enterprises have it's own lawyers working on it.

[szaghi]

I think that the goal to add a guideline on this topic is too far from my possibilities... there are a lot of English issues with respect Fortran ones 😄

I feel that I will not able to provide a draft on this topic, sorry. Anyway I will contribute as much as possible.

[victorsndvg]

Hi,

only for your information, I've found a post talking about "license compatibility and relicensing"
https://www.gnu.org/licenses/license-compatibility.html

[szaghi]

@victorsndvg Thank you very much.

@ALL : I am currently busy, but I will come back soon (sounds like a threat 😄 ).