derivative works/license

[jordens]

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).

[dhslichter]

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
https://www.gnu.org/licenses/gpl-faq.html#GPLUSGovAdd

http://dodcio.defense.gov/Open-Source-Software-FAQ/#Q:_Can_government_employees_develop_software_and_release_it_under_an_open_source_license.3F
http://dodcio.defense.gov/Open-Source-Software-FAQ/#Q:_Can_government_employees_contribute_code_to_open_source_software_projects.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.

[dnadlinger]

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.

[jbqubit]

For the purposes of my comment I define two operational terms. 1)
"ARTIQ Python" for the language processed by the ARTIQ compiler in
which end-users experiment files are written. 2) "ARTIQ OS" for the
rest of the ARTIQ codebase including the ARTIQ python compiler,
runtime, RTIO interface, GUI, hardware-specific extensions to include
NDSP, RTIO PHYs, real-time signal processing and anything else written
in MIGEN.

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).

I advocate for (b). Here, programs written in ARTIQ Python are not
considered derivative works.They are "code" to be compiled for
execution in ARTIQ OS. This is analogous to the GCC compiler and
standard library which are covered by GNU GPLv3. But owing to the
"Runtime Library Exception" in the license, GCC can compile (and link
with) proprietary code without the result being considered a
derivative work. An excerpt from the license follows.

"When you use GCC to compile a program, GCC may combine portions of
certain GCC header files and runtime libraries with the compiled
program. The purpose of this Exception is to allow compilation of
non-GPL (including proprietary) programs to use, in this way, the
header files and runtime libraries covered by this Exception."

https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html

While transparency is desired in science I think many scientists would
shy away from ARTIQ if its use obligated public release of experiment
and data analysis code. In time I hope our culture converges on
openness but we're certainly not there yet. To my view it's better to
let universities, science funders and publishers hash out what level
of data/analysis disclosure is right for different scientific
communities. Most scientists write crappy code anyway so it's not
likely to be of much use to the broader ARTIQ user community.

In contrast, the ARTIQ community has a strong interest in avoiding
fragmentation of the underlying ARTIQ OS and in encouraging code
reuse. Quantum information science has reached a stage where serious
groups are increasingly multi-disciplinary and often hire experts in
electrical engineering and software development. Such expertise is
needed when underlying parts of the ARTIQ OS need to be extended. In
my observation engineers occasionally write reusable code that ARTIQ
can assymilate. I recommend maintaining GPLv3+ for the codebase so
such modifications are explicitly considered derivative works.

Companies can build proprietary hardware which is compatible with
ARTIQ. The source for the ARTIQ drivers for their hardware would be
derivative and subject to the GPL. In analogy to Linux kernel
extensions, these drivers could be included in ARTIQ. In this way an
end user could buy a quantum widget, download stock ARTIQ and start
working. This protects the right of an end user to tinker with and
combine widgets in ways manufactures might not anticipate.

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 for fear of having to release some
or all of their code/hardware design, depending on the
interpretation of what counts as derivative work.

The driver for a piece of hardware can be GPL'd without the hardware
itself being subject to the GPL.

---

Joe Britton
Sensors and Electron Devices
Army Research Lab
2800 Powder Mill Rd
Adelphi, MD 20783
301-394-3130
joseph.w.britton5.civ@mail.mil

On Mon, Oct 3, 2016 at 4:17 PM, dhslichter notifications@github.com wrote:

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
https://www.gnu.org/licenses/gpl-faq.html#GPLUSGovAdd

http://dodcio.defense.gov/Open-Source-Software-FAQ/#Q:_Can_government_employees_develop_software_and_release_it_under_an_open_source_license.3F
http://dodcio.defense.gov/Open-Source-Software-FAQ/#Q:_Can_government_employees_contribute_code_to_open_source_software_projects.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 for fear of having to release some or all of
their code/hardware design, depending on the interpretation of what counts
as derivative work.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[sbourdeauducq]

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).

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.

[dhslichter]

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).

[dhslichter]

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).

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.

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".

[sbourdeauducq]

That should still be fine. https://www.gnu.org/licenses/gpl-faq.html#CombinePublicDomainWithGPL

[dhslichter]

OK. Thoughts on Joe's argument for option b), distinguishing "ARTIQ Python" from "ARTIQ OS"?

[jordens]

@dhslichter:

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.

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.

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?

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'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.

I think many scientists would shy away from ARTIQ if its use obligated public release of experiment and data analysis code.

Nonsense. You don't have to release anything! Stop spreading that FUD.

Most scientists write crappy code anyway so it's not likely to be of much use to the broader ARTIQ user community.

Good god. That is one of the worst and most disappointing arguments one could come up with. It's also irrelevant.

I recommend maintaining GPLv3+ for the codebase so such modifications are explicitly considered derivative works.

No! Modifications are always derivative works and distribution of modifications would always inherit the same license.

Companies can build proprietary hardware which is compatible with ARTIQ. The source for the ARTIQ drivers for their hardware would be derivative and subject to the GPL. In analogy to Linux kernel extensions, these drivers could be included in ARTIQ.

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).

[dhslichter]

@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.

[jordens]

@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 is why I referred to companies like NVidia, ATI, Broadcom and others who have been successfully distributing linux kernel drivers for their hardware under their own non-open license as proprietary modules for decades.

[jbqubit]

In my view the definitions and the technicalities of constructing an
ARTIQ OS/ARTIQ Python etc. are broken and not helpful.
I am certain that we can easily shoot holes into those definitions/distinctions.
@jordens Is there a different parceling of the code that you think is
better? I'd like to distinguish between "programs written by
scientists to control experiments" and "the rest of ARTIQ". If were
done with fewer holes perhaps Section 7 of GNU could be invoked.
Perhaps I should have quoted a bit more generously from the GCC
example.

"This GCC Runtime Library Exception ("Exception") is an additional
permission under section 7 of the GNU General Public License, version
3 ("GPLv3"). It applies to a given file (the "Runtime Library") that
bears a notice placed by the copyright holder of the file stating that
the file is governed by GPLv3 along with this Exception.

When you use GCC to compile a program, GCC may combine portions of
certain GCC header files and runtime libraries with the compiled
program. The purpose of this Exception is to allow compilation of
non-GPL (including proprietary) programs to use, in this way, the
header files and runtime libraries covered by this Exception."

https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html

@dhslichter suggested that M-Labs include language to clarify what
they believe is or is not derivative. I support this.

[jordens]

@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:

• experiments
• kernels vs. host code in experiments
• custom applets and the libraries they might use
• custom data crunching code, also code that is shipped with an experiment but gets distributed to (and "linked" with) remote controllers
• data analysis code and the libraries used therein
• code that exercises the various ARTIQ network protocols and e.g. controls ARTIQ components or listens to events
• custom remote controllers
• custom remote controller-wrappers that "adapt" pre-existing proprietary devices and drivers
• meta-programming/templating code that generate ARTIQ experiments
• custom RTIO channel
• RTIO-channel wrapper that "adapts" a pre-existing proprietary core to make it available as an RTIO channel

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?
It was not Daniel who suggested clearing the interpretation of "derivative" using some written statement. That was one of the options already suggested in the top post above.

[jordens]

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?

[jmizrahi]

@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.

[jordens]

@jmizrahi @dhslichter @jboulder
Just to broaden then horizon here: another reason not to go for LGPL is that we would not be able to link/include GPL code in ARTIQ anymore. Because the networking stack that we use currently (lwip) is not all that great, we were looking for better alternatives. picotcp is an active, mature, and clean stack that we like. And it was just recently re-licensed as GPL (tass-belgium/picotcp#408). Now, making ARTIQ LGPL but bundling/linking/including picotcp under GPL, would make the entire package GPL.

[dhslichter]

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?

[jordens]

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.

[jordens]

Gnuradio for example is GPL.

[jbqubit]

@jmizrahi It looks like the Sandia control code also uses GPLv3. Will Sandia be re-releasing under LGPL?
http://www.osti.gov/scitech/biblio/1326630
https://github.com/pyIonControl/IonControl/blob/master/license.txt
https://github.com/pyIonControl/IonControl-firmware/blob/master/LICENSE

[jordens]

Consensus is to relicense ARTIQ under LGPL3+.

We want [IC]CLAs.
Other projects just follow the Apache pattern/text: http://www.apache.org/licenses/
See https://issues.apache.org/jira/browse/LEGAL-100 for govt/public domain stuff.

[dhslichter]

OK, so for now we are foreclosing on the options of picoTCP, Gnuradio, etc?

[jordens]

Picotcp yes, but we seem to have a reasonable alternative.
Gnuradio and others under configurations where we would link ARTIQ against them yes. But you can still distribute e.g. an ARTIQ controller that links against/uses gnuradio under GPL.

[whitequark]

@jordens Is there any discussion yet to happen here?

[jordens]

No. We just have to dig up all the contributors and have them signal consent.

[sbourdeauducq]

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.

[jordens]

It seems highly likely that either lwip is fixable or that the other to-be-released stack is suitable.

[whitequark]

We've merged smoltcp, which is released under 0-clause BSD, so the TCP/IP stack is no longer a constraint.

[jordens]

Yep. Waiting for just one more contributor.