-
Notifications
You must be signed in to change notification settings - Fork 201
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
derivative works/license #570
Comments
The consensus after a large discussion here was that relicensing under LGPLv3+ is the way to go. The main issue stems from the fact that work performed by US government employees is not subject to copyright (public domain), and as such cannot be released by the government under any license. If ARTIQ is GPL'ed, then we cannot release any of our code without there being a conflict (since ARTIQ would require us to release it as GPL, in conflict with federal law placing it in the public domain). It does seem under the understandings in the GPL/LGPL documentation that ARTIQ experiment code we write in the lab should be considered a derivative work. LGPLv3+ would fix this by allowing us to release our code under the terms of our choosing (namely, license-free). Federal employees can still contribute to ARTIQ without affecting the choice of license used by ARTIQ; however, those specific parts of ARTIQ contributed by federal employees are technically public domain, and may be used by anyone for any purpose regardless of the license for ARTIQ as a whole. Since these parts constitute only a very small part of the total codebase, which is not very useful in the absence of the rest of the code (to which M-Labs holds the copyright), I don't think it should be an issue. https://www.gnu.org/licenses/gpl-faq.html#GPLUSGov http://dodcio.defense.gov/Open-Source-Software-FAQ/#Q:_Can_government_employees_develop_software_and_release_it_under_an_open_source_license.3F Another consideration arises from whether third-party manufacturers want to make ARTIQ drivers for their (likely proprietary) hardware -- I am talking about something more at the level of the Sayma hardware than ARTIQ drivers for a voltmeter, for example. LGPLv3+ affords them considerably more leeway than GPLv3, which might be so restrictive as to scare many away from undertaking this development, either for fear of having to release some or all of their code/hardware design, or because they use proprietary components in the construction of their system that cannot be GPL'ed. |
How do you interpret the "linking" clause of the LGPL for Python code? Has that interpretation been tested in court? I've no intention to participate in a license debate – nor am I in a position to do so –, but let me just point out that to me it seems like this will mostly serve to create more confusion about the licensing status rather than clearing things up. |
For the purposes of my comment I define two operational terms. 1)
I advocate for (b). Here, programs written in ARTIQ Python are not "When you use GCC to compile a program, GCC may combine portions of https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html While transparency is desired in science I think many scientists would In contrast, the ARTIQ community has a strong interest in avoiding Companies can build proprietary hardware which is compatible with
The driver for a piece of hardware can be GPL'd without the hardware Joe Britton On Mon, Oct 3, 2016 at 4:17 PM, dhslichter notifications@github.com wrote:
|
As your second FSF link points out (https://www.gnu.org/licenses/gpl-faq.html#GPLUSGovAdd) there is no such conflict. Your second defense.gov link says the same. It would only make ARTIQ a mix of GPL copyrighted code and public domain code, which is not an unmanageable situation. |
Since it is the prerogative of the copyright holder to enforce violations of licensing, it falls within M-Labs's power to describe what it would consider to be derivative vs not derivative work. Whatever happens with the license decision, I think it would be important for M-Labs to have a document included with ARTIQ explicitly stating their stance on what is considered derivative vs not (for example, if the distinction between "ARTIQ Python" and "ARTIQ OS" that Joe suggests is adopted, it would be very helpful to make this clear in a description so that users/contributors know where they stand). |
The distinction here is a subtle one in my reading; if we contribute something to ARTIQ, it is part of ARTIQ. ARTIQ as a whole can be protected under whatever license, but the parts contributed by federal employees are public domain. However, if we release our own experimental codebase as a separate entity, if this is considered a derivative work of ARTIQ then the code developed by NIST must be GPL'ed under the GPL license. There is not a mixture of GPL-able parts and public domain parts which can be put under the larger umbrella of GPL for the whole package, because the whole package is public domain. I guess I see a distinction between contributing to a mixed project vs. the government releasing something entirely on its own, thus the reasoning. It is the distinction between the first and second links I sent. The question is whether one considers our experimental codebase, if released by itself, as an "improvement" to ARTIQ, or as a separate "program". |
That should still be fine. https://www.gnu.org/licenses/gpl-faq.html#CombinePublicDomainWithGPL |
OK. Thoughts on Joe's argument for option b), distinguishing "ARTIQ Python" from "ARTIQ OS"? |
I don't see why the USGov/public-domain stuff (that was already discussed a long time ago) is relevant here. I also don't see where -- as you state -- GPL requirements about derivative works are in conflict with federal law. Copyright and Licenses are well distinguishable and do not come into conflict.
Please stop implying that there is fear and please stop fueling that hypothetical fear. It is highly irrational to silently subscribe to an open source project, use and benefit from it, and then "fear" that you have to publish something. You don't have to publish anything. And if you use proprietary components in the construction of the system, then that's completely fine. Why would you have to release them?
That's not specific to government employees at all. But it is precisely what sparked this issue. @klickverbot Are you saying that with LGPL we would be in a situation where "linking"/"importing" has less clear implications in (legal) practice than with GPL? In my reading, in that of the FSF, and in that of many LGPL python projects it seems to be the opposite: LGPL's implications are clear. They might not have been tested in court yet. But that seems a bit secondary as even there one would assume that if the copyright holder expresses his intentions through the license in a clearer fashion, the courts would understand him better. @jboulder: In my view the definitions and the technicalities of constructing an ARTIQ OS/ARTIQ Python etc. are broken and not helpful. You are trying too hard to press this into some FSF lingo that was designed for a very different case. I am certain that we can easily shoot holes into those definitions/distinctions.
Nonsense. You don't have to release anything! Stop spreading that FUD.
Good god. That is one of the worst and most disappointing arguments one could come up with. It's also irrelevant.
No! Modifications are always derivative works and distribution of modifications would always inherit the same license.
No! The analogy is not with the typical (open source) modules in the kernel but with things like the old AFS code and the NVIDIA drivers. Those are widely not considered derivative works even though the FSF considers them to be by virtue of their interpretation of "linking". As a clarification, by (b) I meant "publicly stating" the intent, reiterating the issue and the interpretation, like Daniel describes. Not stating through a custom license exception. To me, the later seems too fragile, unqualified and complicated. But let's call "adding a license exception for Experiments" option (d) in order to distinguish it from (b). |
@jordens my use of the word "fear" was perhaps inapposite; I understand that nothing in the ARTIQ license requires anything of people who just want to use ARTIQ (i.e. no lab is required to release their code or any such thing). My paragraph there was intended to relate to some third-party vendor (say Toptica, or MOGLabs) which wants to make ARTIQ-compatible hardware and drivers for the same. My concern was that if we use GPL, the degree to which they would have to release the source code for their drivers, and/or hardware details, is not very clear to me. Many small companies like this are very circumspect about what they consider to be their intellectual property, and so the "fear" I mentioned might be better characterized as "reluctance" to engage in development integrated with ARTIQ if it requires them to divulge too much information that they would consider proprietary. This is not a show-stopper, but it is a consideration. Again, I am not saying that there is no solution that could be worked out with GPL, but simply that LGPL will resolve some of those potential issues in the minds of such third-party vendors. There are of course others, like Creotech, who are happy to be on board the open-source wagon with everything, and that is a big plus for all in that instance. |
@dhslichter Ack. But I maintain that even that "reluctance" effectively does not exist in practice and is only hypothesized (by third parties). Maybe arising from a lack of familiarity and experience with open source software. |
"This GCC Runtime Library Exception ("Exception") is an additional When you use GCC to compile a program, GCC may combine portions of https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html @dhslichter suggested that M-Labs include language to clarify what |
@jbqubit You are still implying that it is possible to press ARTIQ into that OS/program terminology that you found. Just a few things that your hypothetical parceling would need to be identify and slot unambiguously:
In the light of how tedious and fragile this would seem to become, I'd prefer to stay at an abstract level and use the language of "combining or linking" (LGPL) and exclude combined works conceived in such a way. What do you want to say with the copy-pasted stuff? |
As a small test and bit of homework for those physicists who "have written code" but don't have experience publishing or contributing to open source projects: where in your past coding experience would the provisions of GPL have impacted in a way that you would have considered unacceptable? |
@jbqubit May I ask why you dislike the simple solution of going with the LGPL? It seems to me that this makes unambiguous the status of both physicist code and any proprietary hardware drivers, as Daniel mentioned. Any direct improvements to ARTIQ are still covered under the same open source requirements as the GPL. I agree with Robert that any attempt to split up ARTIQ in the way you describe will lead to more ambiguity and confusion, not less. The terms of the LGPL, however, seem clear. |
@jmizrahi @dhslichter @jboulder |
My issues regarding NIST's ability to release code have been resolved, and I think that the question of whether GPL would limit interest from potential collaborating vendors has been addressed to some degree. An issue like lwip vs picotcp, where ARTIQ really wants/needs to make use of a superior component which is GPL, seems like a compelling rationale. Are there other GPL packages that ARTIQ might want to include? Are there non-GPL networking stacks besides lwip that would work? |
There are certainly many interesting GPL packages that could be good to link/use/includ in the future. Right now, I don't know of any particular one that is urgently needed. Alternative good networking stacks are scarce. There might be exactly one other. Having to drop picotcp due to the license would certainly leave us with only that option. |
Gnuradio for example is GPL. |
@jmizrahi It looks like the Sandia control code also uses GPLv3. Will Sandia be re-releasing under LGPL? |
Consensus is to relicense ARTIQ under LGPL3+. We want [IC]CLAs. |
OK, so for now we are foreclosing on the options of picoTCP, Gnuradio, etc? |
Picotcp yes, but we seem to have a reasonable alternative. |
@jordens Is there any discussion yet to happen here? |
No. We just have to dig up all the contributors and have them signal consent. |
I wouldn't be so fast. If PicoTCP turns out to be the only sensible way to fix those horrible network bugs, then we are stuck with the GPL. |
It seems highly likely that either lwip is fixable or that the other to-be-released stack is suitable. |
We've merged smoltcp, which is released under 0-clause BSD, so the TCP/IP stack is no longer a constraint. |
Yep. Waiting for just one more contributor. |
Kelly Stevens: 1481043941095.63542@gtri.gatech.edu David Nadlinger: E7C03799-5D45-4C03-9DF9-029FE2B4F12B@klickverbot.at whitequark: 69d1ca29d5ab03fbcfb446d65cbe1150@mail.whitequark.org Felix Held: 9145cc19-2319-3516-b2a9-dde60aef11f7@felixheld.de Robert Jordens: CANb+zoFgXVYgCji_vXPauK-fnnYKpm_QioMnvmh=hvLFWQONWA@mail.gmail.com Daniel Slichter: BL2PR09MB1010FE3D3A325E889AD70A2591820@BL2PR09MB1010.namprd09.prod.outlook.com Joe Britton: CAE2_b1V60_6PJ3VYx_s-p5XVfKJUx8kbQA7VwD3MdcmHdzROGw@mail.gmail.com Florent Kermarrec: CA+96J6JHM8yZM=RYaporU36NdyOTL3BeSuO9oM8TTtdnXiJ5jw@mail.gmail.com Zach Smith: CAAJ=EH+OzDs_rBJ_zTjbOZmumEZWONX2MSFUasJwf8josJGdkw@mail.gmail.com David Leibrandt: CY1PR09MB0921C628EC76CDFC4CC7F64F95820@CY1PR09MB0921.namprd09.prod.outlook.com Raghavendra Srinivas: DM5PR09MB1531C49EEE1774DF2BA80616F8850@DM5PR09MB1531.namprd09.prod.outlook.com Yann Sionneau: CACi+aWbdY48D9CgKtXdtVsdX4NS1JwVN4v-PCC17F_rPKSt4XQ@mail.gmail.com Sébastien Bourdeauducq: c3f235dc-e9c5-7f7a-10f2-bb4e4f85e7f5@m-labs.hk
ARTIQ is licensed and distributed under GPLv3+. It is used under that license in the labs. Now, an experiment (importing artiq, inheriting from EnvExperiment), additional data processing code that uses artiq, or changes and additions could be considered a derivative work and would then also inherit the GPL license. Then, for example when giving your experiment code to somebody else, it would be a distribution of a derivative work and would again need to be under the terms of the GPL.
Whether importing artiq and inheriting from some part of artiq actually does form a derivative work in practice is undecided. The FSF says it does while some case law in the US says it doesn't, Linux kernel developers say it doesn't under certain conditions, and legal opinions also say it is unclear and that merely importing and inheriting are not sufficient to form a derivative work.
Looking around, there are many scientific and academic cases and fields where it is common and laudable practice to expect or even demand that derivative works are published and distributed under equally open terms.
http://sciencecodemanifesto.org/
The Legal Framework for Reproducible Scientific Research: Licensing and Copyright http://doi.ieeecomputersociety.org/10.1109/MCSE.2009.19
At least a clarification of the situation would seem to be wise.
We could either:
a) state that we consider physicists' expriments that use artiq (import from artiq,
inherits from EnvExperiment etc) to be derivative works
b) we state that we don't, or
c) we relicense ARTIQ under LGPLv3+ (which excludes code that "uses" artiq from becoming a derivative work).
@dtcallcock @dleibrandt @dhslichter @r-srinivas and whoever else I am forgetting: could you gather/describe the view of the Ion Storage group on this?
@jbqubit
@m-labs is not opposed to any of a,b,c.
I would prefer a) and would consider it to be proper scientific ethics, but would not be completely opposed to c).
The text was updated successfully, but these errors were encountered: