GPL and virality

@ChrisRackauckas: Yes I understand you. You want code exchange without any overhead (thinking about licenses). And this is fine if all contributors agree. You can also ask someone (friendly) if you can reuse the code of him/her. I just want to give a hint that nobody should be blamed because he/she uses GPL.

2 Likes

No this is wrong. Julia base library does use external GPL code that is dynamically linked. The situation is exactly the same as for packages.

There is an GPL free compile time option but in that case you would of course not have that functionality. (master may now be GPL free, don’t want to make a misinformed statement)

Oh, good point. Another testament of how little I grasp this subject.

If one of the A, B, C parts is GPLv3 then D as a whole has to be GPLv3 also. I don’t mean viral pejoratively, I mean it in the sense that the license of one of the parts extends to the resulting bundle. AFAIK this is different when using e.g. MPL, Apache License, LGPL, MIT, BSD, etc.

But maybe it’s not so important with interpreted languages? One could (probably?) argue that the files will/could be distributed individually. And there is no binary were files have been compiled into.

Except for ‘selfish’ I fully agree (would rather have said pragmatic (like e.g. Torvalds in the GPL2/3 discussion))

Here I have a different view. Example (using your Julietta package):

  • if I wanted to use parts of your GPL3’ed package together with my/other GPL2 licensed code, I couldn’t do this. If I wanted to use it together with proprietary components I couldn’t
  • you wrote: “Julietta is licensed under the GPLv3. For code conributions: As the original author of this work I want to keep right to spin off a commercial version of this software.”. If the julia base library were GPL3, I think, you couldn’t do this, as you were bound also to GPL 3 (I don’t know if you used ‘julia base code’, so maybe I’m wrong here - but wouldn’t all usage of core base code (if it were GPL3) raise the questions: have I taken enough substantial code such that my resulting product has to be GPL3 too?)

Please don’t misunderstand me: It’s perfectly fine to choose, GPL3. I only want to point out, that there are consequences. (In your case, :grin: , I would rather look at the ‘GtkIDE.jl’ package which is MIT licensed - just as an illustration, not that it would matter in reality.)

How to tackle that would have been my personal problem. There is a simple solution → remove all GPL parts from Julia and one can distribute it. I would have done it, if I wanted to go further that route but plans have changed such that I abandoned Julietta. At that point I wanted to keep the option to make a business out of it.

Non-native speaker here. I wanted to express that the individual that asks someone to change the license is motivated by the goal that he/she gets more(!) rights than he/she would have without the license change. He/she does not care that the individual that GPL licensed the code will lose(!) rights. selfish in this context should mean: I put my own goals over that of another.

1 Like

But isn’t this exactly the crux? When using a copyleft license, one would have to remove those parts when a non-copyleft license is wanted in future. Then in addition there would be another problem: if one has studied a certain GPL package intensively in all details, I don’t think, one could ‘just’ remove all GPL parts again. At least it would be a bit delicate to defend that it is a clean room re-implementation. (But imnal, and not a native english speaker either).

Is Julia GPL-free now by default or only when compiled with USE_GPL_LIBS=0?

The LICENSE.md file suggest that the GPL dependency remains, but it may be outdated.

1 Like

I would assume the GPL still holds even with an interpreted language. Just having the source code only, protects freedom 0 and 1, but not i.e. 2 (legally) or the last one the GPL was made for: “The freedom to distribute copies of your modified versions to others (freedom 3).”

Yes, you CAN still do that, but e.g. patents or just a proprietary license file (or no license file, i.e. by default proprietary) would still disallow you doing that without fear of being sued.

Note that the GPL does not stop you from doing anything in private.

E.g. with A Julia the runtime (or even the bundled libraries), that program could in theory all be under the GPL (i.e. not using MIT license from the start), and it that alone still wouldn’t “infect” code you run with it. Only if you distributed that Julia with the code would GPL restrictions apply. To that combination (in theory Julia could be reimplemented as MIT only…).

If you distribute code made to run using Julia to others without the Julia runtime itself, I would argue that the “systems library” exception of the GPL would apply, for using the runtime (and the GPL libraries).

I believe there are more GPL components, by default. You could argue if you distribute Julia with your code, and not actually use it, it would as “dead code” fit under “mere aggregation” clause. I would not test that theory, and not just distribute the runtime with my code, or be sure to first strip out the GPL libraries that usually come with the runtime.

I believe none that is still used by default, for everyone (still e.g. sparse matrix code in under GPL?). There’s some GPL, like for git that’s ok, as it has an exception.

Note, that package is actually under the LGPL, which makes it less important to use the same license for the wrapper. It also points out LGPL in the LICENSE file. For wrapping GPL libraries, I would say just use the GPL for the wrapper too, or at least make it crystal clear in the LICENSE same file, and any file that mentions e.g. MIT license, that it’s a wrapper for the GPL. Not doing it isn’t fine by me and I’m not sure if it is, but at least and should be illegal.

You actually usually can, when the recommended phrase “either version 2 of the License, or (at your option) any later version” is used.

I don’t see the crux here. It is perfectly possible to distribute Julia in a closed source application but it requires some work (for instance finding/implementing a replacement for FFTW). But this should be the problem of people who want to distribute Julia and it should not(!) be the problem of the open source developers contributing to Julia. It requires me two days to replace FFTW.jl with a non-GPL version that provides the same functionality (though not as fast). But currently I would never ever spend these two days since I don’t want to distribute Julia in a closed source application.

Regarding looking at GPL code: Don’t do that if you want to develop the same functionality in a MIT based application. But this basically holds for any material in the internet.

Strictly speaking, this can be very difficult to implement in practice. A single @edit can take you any kind of code.

with great power comes great responsibility… :wink:

Open source is not a free shop. It means that one has to understand copyright and licensing. So if you want to study the source code of a package you should first have a look at the license and then decide if you want to look at it. Sounds annoying. But is the only way prevent oneself into a situation that may violate the license behind that software. When no license is given, copyright holds. So don’t read that code if you want to implement something similar. This is not GPL specific as Steven outlined at the beginning of this thread.

I agree with you about the free shop aspect; I was merely pointing out that in practice, this could be a motivation for a particular language community to encourage MIT or similar licenses. Especially in scientific programming, where it is in fact good practice to study each other’s code all the time (of course one can argue that it should all be GPL, problem solved :smile:).

2 Likes

This only means that you can’t distribute GPL software with an NDA attached. It doesn’t prevent you from doing research under an NDA using GPL software (or code derived therefrom). But you can’t give GPL code to someone else and tell them they can’t release it.

Really, this is not that complicated: if you give someone code under the GPL and also tell them it is under NDA, you are contradicting yourself.

The whole point of the GPL is to prevent people from distributing code based on yours with additional restrictions attached. This is not a bug, it is the goal of the license. You may not want such a license — you may want to allow people to take your code, incorporate it into proprietary software, attach NDAs, etcetera — but you can’t complain that preventing this is an unintended consequence of the GPL.

10 Likes

At the risk of belabored internet-lawyering…

I know and appreciate that you have good intentions here, but this strikes me as very misleading. The link that you posted to the FSF page covers NDA in the context of distribution, which is always the context in which the responsibilities of the GPL are incurred (the AGPL is a somewhat different story, of course).

There is nothing in the GPL preventing author(s) who happen to have released code under GPL in the past – related or not – from entering in to a contract specifying, for example:

  • the results of any work with unreleased hardware or specs shall not be publicly disclosed until a specific date. They can work on a private fork only accessible to others under NDA, exactly like direct employees, contractors, or collaborating authors of any proprietary or MIT-licensed library would, and only merge into the public tree after the agreed date.
  • that they may not release incidental trade secrets gleaned in the course of research. By incidental, I mean outside the scope of code directly implementing – for example – support for the new hardware in a compiler (if the goal is not embodiment in code, for eventual release, then what would be the point?). You could even stipulate pre-release code review, though at the point they would basically be contractors, and hopefully compensated.

Now, it is entirely possible that some library authors object to such NDA obligations for philosophical reasons. It is also conceivable that your lawyers do not like or trust those damn dirty GPL-hippies, and so they come up with excuses to make the question go away (or they did do 20 years ago, and the policy stuck).

But both of those responses are unrelated to the legal implications of the GPL itself.

Here’s a concrete example of Red Hat and TI doing exactly what I mention above, to provide GCC support for new hardware.

(if I am misunderstanding the context here, please do clarify so that people don’t misinterpret the scope of your comments. the idea that “Intel’s lawyers believe X” carries significant weight, even 2nd-hand)

6 Likes

I shared information I thought would be useful, based upon years of working on both sides of the vendor-researcher relationship and having discussed this precise topic with lawyers who focus on software licensing. I will avoid commenting on this topic in the future, since clearly it was not constructive to have done so here.

3 Likes

I found the information about potential GPL/NDA conflicts useful – I had not been aware of the issue previously. I think the only disagreement here is about under what circumstances such a conflict exists and is a problem, which is a somewhat murky legal area. Please don’t take this back and forth the wrong way – I for one did not interpret your comments as FUD. Somehow discussion about the GPL seem to often become a bit contentious.

4 Likes

I apologize if I read too much in to your comment, or if my post came across the wrong way.

It is certainly very useful for people to know that a specific company might decline to share pre-release information with them, if they have written GPL software in the past. Obviously that is the company’s choice, and it could be an important consideration for some developers. Thank you for sharing that.

The thing I am objecting to is what I read as a generalization that this is inherent to the GPL, rather than a specific company’s preference. Many other companies maintain private forks for internal development, or pay contractors to improve GPL software in private long before public release (and, just to be clear, I’m talking about good open source citizens who do fulfill their GPL compliance obligations completely – not violators). None of which would be possible if the GPL implied a requirement of continuous public development or immediate disclosure of all related knowledge. The GPL is a neat copyright hack, but it doesn’t abrogate contract law outside of its scope. (or to put it another way: the GPL can’t compel me to share code I haven’t even written).

1 Like

https://www.gnu.org/licenses/gpl-faq.en.html#DevelopChangesUnderNDA

Does the GPL allow me to develop a modified version under a nondisclosure agreement?

Yes […]

Note, they are authoritative, and only answer “No” to two of three questions on NDAs. Just read the fine print on these questions.

Note also, the GPL only applies to distribution/conveying, it doesn’t restrict what you do in private. Note more, that may apply, e.g. as an employee:

https://www.gnu.org/licenses/gpl-faq.en.html#InternalDistribution

[…] As a consequence, a company or other organization can develop a modified version and install that version through its own facilities, without giving the staff permission to release that modified version to outsiders.

However, when the organization transfers copies to other organizations or individuals, that is distribution. In particular, providing copies to contractors for use off-site is distribution.

https://www.gnu.org/licenses/gpl-faq.en.html#UnreleasedMods

https://www.gnu.org/licenses/gpl-faq.en.html#v3CoworkerConveying

https://www.gnu.org/licenses/gpl-faq.en.html#TradeSecretRelease

1 Like