Updating Genode's license to AGPLv3 + open-source linking clause

[Norman Feske]

Dear community,

with the upcoming release 17.02, we are planning to change Genode's
open-source license.


The current GPLv2 license
-------------------------

The Genode OS Framework is currently licensed under the terms of the
version 2 of the GNU General Public License. We originally picked this
license in 2008 for the following reasons:

* It captures the spirit of Free Software, which we deeply share with
the FSF. The license ultimately empowers the authors and the end
users of software. Genode would not exist without Free Software. It
is built on the shoulders of software like GCC, the GNU system, or
Linux. All software that we at Genode Labs develop is Free Software.

* At the time of the first Genode release, the GPLv2 was a time-tested
and widely used license.

* It enables the dual-licensing business model of Genode Labs. If
Genode is commercially leveraged for proprietary solutions, Genode
Labs benefits from the success of such products. This way, Genode
has a long-term strategy to fund its development without relying on
donations, public funding, or venture capital. We value this
independence as fundamental for the sustainability of our project.

* Adopting the same license as Linux made a lot of sense because we
are routinely reusing Linux driver code inside Genode components.


Affero General Public License
-----------------------------

The time did not stand still. The GPLv3 became widely spread and
well-understood. It rectifies several shortcomings of the GPLv2.
Furthermore, the Affero General Public License [1] closes loopholes of
the GPL license with respect to web applications. Unlike 2008 when most
applications were programs executed directly on the end user's computer,
web applications have become predominant by now.

For Genode, we ignored the deficiencies of the GPLv2 for a long time. At
the same time, with more and more software being added to our "ports" -
the library of 3rd-party software ported to Genode - the license
compatibility question, which we tried to avoid for Linux kernel code,
arises for other 3rd-party software that is combined with Genode.

Admittedly, one reason for our hesitance was our fear of long-winded and
opinion-loaded discussions around the licensing topic. But we ultimately
have to acknowledge that an update to a modern license and a
clarification of our stance with respect to the interoperability of
Genode with other Open-Source software is long overdue.

The AGPLv3 encapsulates exactly the spirit, which originally attracted
us to the GPL. After careful review, it makes perfect sense to use it
for Genode. The following Wikipedia article nicely explains the
rationale behind this license:

https://en.wikipedia.org/wiki/Affero_General_Public_License


Addressing interoperability concerns
------------------------------------

Unlike most end-user software, which falls into a tangible category
(application, library, kernel), Genode plays a special role. Not just
because it is an operating system. But it is very unconventional at
that: It is a collection of programs (Genode components). It is also a
set of application libraries. It is also a "system library". It also
comprises a dynamic linker. It may also be the kernel (i.e., our base-hw
kernel). The lines between the categories become blurry.

For this reason, we intend to add a linking clause to Genode's version
of the AGPL license text, similar to the classpath linking exception but
restricted to software licenses that are blessed by the Open-Source
Initiative, the Free Software Foundation, or Genode Labs.

Inspired from the text of the classpath linking exception, our clause
would look as follows:

Linking Genode code statically or dynamically with other modules
is making a combined work based on Genode. Thus, the terms and
conditions of the GNU Affero General Public License version 3
(AGPLv3) cover the whole combination.

As an "additional permission" as defined by Section 7 of the
AGPLv3, Genode Labs as the copyright holder of Genode gives you
permission to link Genode source code with "independent modules"
to produce an executable if the independent modules are licensed
under an "approved license", 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 "approved license" is a license that is officially approved as
an Open-Source license by the Open Source Initiative [1], or
listed as a Free-Software license by the Free Software Foundation
[2], or explicitly approved by Genode Labs.

An "independent module" is a module which is not derived from or
based on Genode.

If you modify Genode, you may extend this exception to your
version of Genode, but you are not obliged to do so. If you do not
wish to do so, delete this exception statement from your version.

[1] https://opensource.org/licenses
[2] https://www.gnu.org/licenses/license-list.en.html

With this clause in place, we want to express our consent to use Genode
in combination with other open-source software. Note, however, that -
unlike the classpath exception clause, our clause excludes the
combination of Genode with proprietary software. This is our deliberate
decision.

With Genode becoming AGPLv3, we face the question of how to integrate
3rd-party code (like GPLv2-licensed Linux device drivers) in a Genode
component. To address this concern, Genode-specific glue code that is
needed to integrate the 3rd-party code with the Genode API ("system
library") will have a license that is compatible with both the license
of the 3rd-party code and Genode's AGPLv3 as such glue code is a
derivative of both Genode and the incorporated code, e.g., the MIT
license. In line with the wording of the exception clause above, when
distributing binaries of such components, the licenses of both Genode
and the incorporated 3rd-party code must be respected.

I hope that you support our plan to relicense Genode to AGPLv3 along
with our linking exception clause. Should you have doubts about us
taking this direction, please let me know.

Best regards
Norman

[Jookia]

Post by Norman Feske
Dear community,
with the upcoming release 17.02, we are planning to change Genode's
open-source license.

Fascinating!

Post by Norman Feske
For this reason, we intend to add a linking clause to Genode's version
of the AGPL license text, similar to the classpath linking exception but
restricted to software licenses that are blessed by the Open-Source
Initiative, the Free Software Foundation, or Genode Labs.

Sounds good.

Post by Norman Feske
Inspired from the text of the classpath linking exception, our clause
Linking Genode code statically or dynamically with other modules
is making a combined work based on Genode. Thus, the terms and
conditions of the GNU Affero General Public License version 3
(AGPLv3) cover the whole combination.

The AGPLv3 also talks about use of the software over a network service, and I
imagine with the focus on IPC and proxying it might be better to clarify this
usage too as a combined work. Unless all this doesn't apply to IPC?

Post by Norman Feske
With Genode becoming AGPLv3, we face the question of how to integrate
3rd-party code (like GPLv2-licensed Linux device drivers) in a Genode
component. To address this concern, Genode-specific glue code that is
needed to integrate the 3rd-party code with the Genode API ("system
library") will have a license that is compatible with both the license
of the 3rd-party code and Genode's AGPLv3 as such glue code is a
derivative of both Genode and the incorporated code, e.g., the MIT
license. In line with the wording of the exception clause above, when
distributing binaries of such components, the licenses of both Genode
and the incorporated 3rd-party code must be respected.

This sounds a bit sketch. Could you elaborate more on how this works?

Post by Norman Feske
Best regards
Norman

Cheers,
Jookia.

[Norman Feske]

Hello Jookia,

Post by Jookia
The AGPLv3 also talks about use of the software over a network service, and I
imagine with the focus on IPC and proxying it might be better to clarify this
usage too as a combined work. Unless all this doesn't apply to IPC?

Admittedly, I don't completely understand the question. Neither AGPLv3
nor our linking exception mention IPC. The use of IPC is unrelated to
licensing.

Let me still try to comment on it: If a custom component uses Genode's
IPC mechanism, it is naturally linked against Genode's base libraries
and uses Genode's API headers (otherwise, it could not invoke the IPC in
the first place). Consequently, when distributing the binary of such a
component to a user or providing the component's functionality as a web
service to a user, the AGPLv3 requires one to also provide the source
code of Genode and the custom source code. Thanks to our exception
clause, the latter does not need to be licensed under AGPLv3 (the custom
code is not "infected" by the Genode's license). Any "approved"
open-source license is fine.

Post by Jookia

Post by Norman Feske
With Genode becoming AGPLv3, we face the question of how to integrate
3rd-party code (like GPLv2-licensed Linux device drivers) in a Genode
component. To address this concern, Genode-specific glue code that is
needed to integrate the 3rd-party code with the Genode API ("system
library") will have a license that is compatible with both the license
of the 3rd-party code and Genode's AGPLv3 as such glue code is a
derivative of both Genode and the incorporated code, e.g., the MIT
license. In line with the wording of the exception clause above, when
distributing binaries of such components, the licenses of both Genode
and the incorporated 3rd-party code must be respected.

This sounds a bit sketch. Could you elaborate more on how this works?

First, let me point you to the excellent FAQ at gnu.org:

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

I will try to explain the situation with own words and examples. In the
following, assume that we want to combine a GPLv2 driver into a Genode
component. We also can - for this discussion - regard AGPLv3 as the same
as GPLv3.

"Combining" can have different forms that must be distinguished:

* Both licenses (GPLv2 and GPLv3) are known to be mutually
incompatible with each other. This means, one is not allowed to copy
GPLv2 code snippets into an GPLv3-licensed source code or vice versa.
This practice would ultimately "re-license" the code snippet. This is
a no-go.

* In practice, 3rd-party code is most often used as an "independent
module". For example, when combining a Linux device driver with
Genode, the Linux device driver is definitely not a derivate from
Genode. Vice versa, Genode is clearly not a derivate of the Linux
device driver. Both were developed independent from each other.

In the latter situation, both parts can in principle be combined. But as
the resulting binary contains both the Linux driver code and Genode, the
licensing terms of both licenses apply. That means, when distributing a
binary, one has to provide all the source code that is needed to
reproduce the binary from source. This includes the Genode source code
and the source code of the Linux driver. In addition, the GPLv3 also
requires one to provide the user with the ability to actually use the
reproduced binary (look for "tivoization"). In short, it is possible to
combine independent modules as long as the license of each individual
module is respected.

In practice, when combining such independent modules, some form of glue
code is needed to interface both parts. This glue code is typically
quite simple, as small as possible, and - in contrast to the
glued-together parts - not of great general value. It is ultimately
"tainted" by the interfaces of both modules. Hence, the question of
license "compatibility" (the first point above) enters the picture.

To go out of the way of possible compatibility concerns, it is a good
practice to use a liberal license for such glue code whenever possible.
However, this ultimately is a case-by-case decision. For example,
consider the Linux device-driver example above. If it is infeasible to
craft the glue code without copying some functions and data structures
from the Linux kernel code into the glue code, the glue code will
naturally inherit Linux' GPLv2 license. But in another situation where
clean interfaces exist and the glue code is written completely from
scratch, it is reasonable to use a liberal license for the glue code
rather than a strict copyleft license like GPLv3. This allows other
(non-GPLv3) projects to reuse parts of the glue code, and it avoids any
friction when contributing generally useful parts of the glue code to
the upstream project.

Could I help to dissolve the "sketchiness" you observed?

Cheers
Norman

[Jookia]

Post by Norman Feske
Hello Jookia,
Admittedly, I don't completely understand the question. Neither AGPLv3
nor our linking exception mention IPC. The use of IPC is unrelated to
licensing.
Let me still try to comment on it: If a custom component uses Genode's
IPC mechanism, it is naturally linked against Genode's base libraries
and uses Genode's API headers (otherwise, it could not invoke the IPC in
the first place). Consequently, when distributing the binary of such a
component to a user or providing the component's functionality as a web
service to a user, the AGPLv3 requires one to also provide the source
code of Genode and the custom source code. Thanks to our exception
clause, the latter does not need to be licensed under AGPLv3 (the custom
code is not "infected" by the Genode's license). Any "approved"
open-source license is fine.

I see. How does proprietary userspace code work then?

Post by Norman Feske
Could I help to dissolve the "sketchiness" you observed?

Many projects have used the idea of glue code as a way to link proprietary and
free software together as a way 'around' the GPL, and this sounds a bit like the
same thing. It's questionable if it works though.

Post by Norman Feske
Cheers
Norman

[Vasily A. Sartakov]

Greetings

Post by Jookia
I see. How does proprietary userspace code work then?

Post by Norman Feske
Could I help to dissolve the "sketchiness" you observed?

Many projects have used the idea of glue code as a way to link proprietary and
free software together as a way 'around' the GPL, and this sounds a bit like the
same thing. It's questionable if it works though.

Through magic wrapper, as usual, when one does not want to share sources but should link with open source library.

@Norman: I think many of us are needed in something like decision tree with examples, what and how we should do with source code, how to wrap own code in accordance with the license.

[Norman Feske]

Hi Vasily,

Post by Vasily A. Sartakov

Post by Jookia
Many projects have used the idea of glue code as a way to link proprietary and
free software together as a way 'around' the GPL, and this sounds a bit like the
same thing. It's questionable if it works though.

Through magic wrapper, as usual, when one does not want to share
sources but should link with open source library.

I am afraid this is a misconception. Thank you for this remark, so I can
rectify it.

Genode's open-source license is (and always has been) fundamentally
incompatible with proprietary software. This is on purpose.

The switch to AGPLv3 does not change that. Also note that the linking
exception that I presented does deliberately not cover proprietary
software but is restricted to open-source software.

For using Genode for proprietary purposes, a commercial license can be
obtained from Genode Labs. By purchasing such a license, vendors of
proprietary products contribute to Genode (and thereby the open-source
community), not by the means of code but by the means of funding.

Post by Vasily A. Sartakov
@Norman: I think many of us are needed in something like decision
tree with examples, what and how we should do with source code, how
to wrap own code in accordance with the license.

If by "your own" code you mean proprietary code, the only plausible
approach to combine it with Genode without a commercial license is
stuffing your code into a virtual machine. The (virtual) machine
interface is an universally accepted license boundary.

Best regards
Norman

[Jookia]

Post by Norman Feske
For using Genode for proprietary purposes, a commercial license can be
obtained from Genode Labs. By purchasing such a license, vendors of
proprietary products contribute to Genode (and thereby the open-source
community), not by the means of code but by the means of funding.
If by "your own" code you mean proprietary code, the only plausible
approach to combine it with Genode without a commercial license is
stuffing your code into a virtual machine. The (virtual) machine
interface is an universally accepted license boundary.

To my understand the GPL and AGPL allow combining with proprietary code as long
as you don't convey it to others. Is this wrong?

Jookia.

[Norman Feske]

Hello Jookia,

Post by Jookia

Post by Norman Feske
If by "your own" code you mean proprietary code, the only plausible
approach to combine it with Genode without a commercial license is
stuffing your code into a virtual machine. The (virtual) machine
interface is an universally accepted license boundary.

To my understand the GPL and AGPL allow combining with proprietary code as long
as you don't convey it to others. Is this wrong?

I presumed that Vasily intends to actually distribute/deploy his own
software. If he keeps it private, he can do whatever he likes.

As a side note, I would prefer to not side-track the discussion too
much. For general GPL questions, one may refer to existing and
comprehensive resources like the GPL FAQ. Let us keep the discussion
focused on Genode's particular case.

Regards
Norman

[Norman Feske]

Hi Jookia,

Post by Jookia
I see. How does proprietary userspace code work then?

please see my reply to Vasily.

Post by Jookia
Many projects have used the idea of glue code as a way to link proprietary and
free software together as a way 'around' the GPL, and this sounds a bit like the
same thing. It's questionable if it works though.

I wonder, is this a vague gut feeling or a well-informed concern? If the
former, I would very much appreciate you to not spread uncertainty. It
is definitely not my intention to work around the GPL!

Genode's license is delicate because Genode plays a number of roles. One
particularly important role for this discussion is its role of a "system
library". As stated in the GPL FAQ, the GPL acknowledges that system
libraries may be proprietary [1]. Even if Genode was solely proprietary,
its role of a "system library" would allow the combination of GPL code
with it (at least the portions of Genode that correspond to the
functionality of a system library).

[1] https://www.gnu.org/licenses/gpl-faq.html#SystemLibraryException

If proprietary software is accepted to have this role but GPL software
would not because of the GPLv2/v3 incompatibility, this would be a gross
contradiction with the spirit of Free Software. Furthermore, with the
linking exception clause, we make our stance unmistakably clear that we
are fine with linking Free Software - regardless of potential
license-version incompatibilities - with Genode.

Please be assured that I'm not careless. In fact, I approached the Free
Software Foundation for reviewing my original announcement and
incorporated their feedback *before* I sent it to the mailing list.

Regards
Norman

[Jookia]

Post by Norman Feske
If proprietary software is accepted to have this role but GPL software
would not because of the GPLv2/v3 incompatibility, this would be a gross
contradiction with the spirit of Free Software. Furthermore, with the
linking exception clause, we make our stance unmistakably clear that we
are fine with linking Free Software - regardless of potential
license-version incompatibilities - with Genode.

The Linux kernel is under the GPLv2 only so the only way to combine code with
this is to comply with the GPLv2's terms. The AGPLv3 adds more restrictions than
the GPLv2 so it's incompatible.

Independent modules (things equivalent to userspace programs in Linux I guess)
are allowed to create executables (this doesn't apply to interpreted languages)
that include Genode code under whatever license they like as long as it's using
an approved open source license.

Genode will provide a liberal license for code that integrates Linux drivers in
to Genode.

Why does the AGPL not apply to the integration code if it uses Genode libraries?

Jookia.

[Norman Feske]

Hello Jookia,

Post by Jookia
Independent modules (things equivalent to userspace programs in Linux I guess)

Linux has a special preamble to the GPLv2 that defines the kernel
interface as a license boundary [1].

[1] https://www.kernel.org/pub/linux/kernel/COPYING

Post by Jookia
Why does the AGPL not apply to the integration code if it uses Genode libraries?

I think we agree that it should not. More generally, it is not our
intention to force-feed the AGPLv3 or any other particular license to
Genode-component developers. The choice of the open-source license of a
component should be up to the component's developer.

The original version of our linking exception clause is somewhat lacking
in this respect. It defines an "independent module" as:

"a module which is not derived from or based on Genode."

This wrongly implies that a component that merely uses the Genode API is
not an "independent module". To better express our intention, an
"independent module" may better be defined as:

"a module which is not derived from or based on Genode, or merely
uses the Genode API as defined in the official documentation."

For example, a component forked from an existing component would not
qualify as "independent". But a custom component that interacts with the
Genode API without copying non-trivial amounts of Genode code into its
own code base would meet the definition of "independent". With
non-trivial, I mean code that implements actual functionality as opposed
to simple boiler-plate code.

Coming back to the glue-code example, with this clarification in place,
it should hopefully be clear that the glue code does not get "tainted"
with Genode's AGPLv3, only by the license of the 3rd-party code.

Would that modification make the situation sufficiently clear to you?

Thank you for your scrutiny!

Regards
Norman

[Jookia]

Post by Norman Feske
Hello Jookia,

Hi again :)

Post by Norman Feske

Post by Jookia
Independent modules (things equivalent to userspace programs in Linux I guess)

Linux has a special preamble to the GPLv2 that defines the kernel
interface as a license boundary [1].
[1] https://www.kernel.org/pub/linux/kernel/COPYING

Post by Jookia
Why does the AGPL not apply to the integration code if it uses Genode libraries?

I think we agree that it should not. More generally, it is not our
intention to force-feed the AGPLv3 or any other particular license to
Genode-component developers. The choice of the open-source license of a
component should be up to the component's developer.
The original version of our linking exception clause is somewhat lacking
"a module which is not derived from or based on Genode."
This wrongly implies that a component that merely uses the Genode API is
not an "independent module". To better express our intention, an
"a module which is not derived from or based on Genode, or merely
uses the Genode API as defined in the official documentation."
For example, a component forked from an existing component would not
qualify as "independent". But a custom component that interacts with the
Genode API without copying non-trivial amounts of Genode code into its
own code base would meet the definition of "independent". With
non-trivial, I mean code that implements actual functionality as opposed
to simple boiler-plate code.
Coming back to the glue-code example, with this clarification in place,
it should hopefully be clear that the glue code does not get "tainted"
with Genode's AGPLv3, only by the license of the 3rd-party code.
Would that modification make the situation sufficiently clear to you?

Yes, that clears it up for me. However, it's unclear to me how this will work
with proprietary relicensing of Genode. How will proprietary Genode distributions
use GPLv2 code from Linux or other copyleft projects, or do they just not?

Post by Norman Feske
Thank you for your scrutiny!

No problem.

Post by Norman Feske
Regards
Norman

Jookia.

[Nobody III]

Am I correct that software that doesn't link directly to any AGPLv3 code
(e.g. code that just uses libc) is okay to have proprietary licenses? That
seems to be the logical interpretation, and probably the most beneficial,
as it wouldn't discourage companies from porting their software to Genode.

Post by Jookia

Post by Norman Feske
Hello Jookia,

Hi again :)

Post by Norman Feske

Post by Jookia
Independent modules (things equivalent to userspace programs in Linux

I guess)

Post by Norman Feske
Linux has a special preamble to the GPLv2 that defines the kernel
interface as a license boundary [1].
[1] https://www.kernel.org/pub/linux/kernel/COPYING

Post by Jookia
Why does the AGPL not apply to the integration code if it uses Genode

libraries?

Post by Norman Feske
I think we agree that it should not. More generally, it is not our
intention to force-feed the AGPLv3 or any other particular license to
Genode-component developers. The choice of the open-source license of a
component should be up to the component's developer.
The original version of our linking exception clause is somewhat lacking
"a module which is not derived from or based on Genode."
This wrongly implies that a component that merely uses the Genode API is
not an "independent module". To better express our intention, an
"a module which is not derived from or based on Genode, or merely
uses the Genode API as defined in the official documentation."
For example, a component forked from an existing component would not
qualify as "independent". But a custom component that interacts with the
Genode API without copying non-trivial amounts of Genode code into its
own code base would meet the definition of "independent". With
non-trivial, I mean code that implements actual functionality as opposed
to simple boiler-plate code.
Coming back to the glue-code example, with this clarification in place,
it should hopefully be clear that the glue code does not get "tainted"
with Genode's AGPLv3, only by the license of the 3rd-party code.
Would that modification make the situation sufficiently clear to you?

Yes, that clears it up for me. However, it's unclear to me how this will work
with proprietary relicensing of Genode. How will proprietary Genode distributions
use GPLv2 code from Linux or other copyleft projects, or do they just not?

Post by Norman Feske
Thank you for your scrutiny!

No problem.

Post by Norman Feske
Regards
Norman

Jookia.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main

[Norman Feske]

Hello Ben,

Post by Nobody III
Am I correct that software that doesn't link directly to any AGPLv3 code
(e.g. code that just uses libc) is okay to have proprietary licenses?

this is not correct because the proprietary code would still linked to
Genode in addition to the libc.

Post by Nobody III
That seems to be the logical interpretation, and probably the most
beneficial, as it wouldn't discourage companies from porting their
software to Genode.

This statement is interesting because it raises the question of the
motives and goals behind Genode. What does "most beneficial" mean?
Beneficial to whom? Let me try to look at this question from different
perspectives.


1. The Free Software user

For an end user who consciously uses a Free Software ecosystem,
proprietary applications are not interesting because they restrict the
freedom of the user. Frankly speaking, I am an example of such a user. I
have not touched proprietary applications on my computer since several
years. But I vividly remember the inconvenience of using opaque
installers, the lack of security updates, the inability to fix bugs, or
the suspicion about backdoors and vulnerabilities introduced by such
applications. The argument that an operating system would be useless
without proprietary applications was probably valid 15 years ago. Today,
the Free Software world is so strong and diverse that this argument does
not hold anymore.


2. The consumer

Many end users are neither aware nor interested in technical details.
They just want to get work done, browse the web, play games, or watch
movies. From the operating-system's perspective, I also see
professionals (like photographers, writers, business users) in this
category. A typical consumer uses the OS that comes pre-installed on the
device, and accepts the inherent dependency from commercial vendors. The
user does not care too much about the uppercase Freedom of software. I
am sometimes such a user. E.g., when using my portable audio player, I
just want to listen to music.


3. The proprietary application vendor

For a proprietary application vendor, the consumer (2) is a business
case. The application vendor wants to create and distribute applications
with as little costs as possible and sell them to the consumer at the
highest price possible. The latter would not be easily possible if the
application vendor published its own "intellectual property" to everyone
for free. Hence, the applications tend to stay proprietary to uphold the
business case. The application vendor has to consider expenses like
paid-for development tools, licenses of commercial libraries, or
app-store fees as cost factors. It is clear that proprietary application
vendors welcome liberally licensed open-source libraries or platforms
for hosting and distributing proprietary software at no costs.


4. The proprietary platform vendor

A vendor may use Genode as the basis of a proprietary platform, for
example an appliance designated for a specific market. But such a
platform may in principle also be targeted at the consumer mass market.
In order to use Genode as the basis of a proprietary platform, the
platform vendor obtains a commercial license of Genode. In this case,
the choice of Genode's regular open-source license is not a concern for
such a platform vendor.


5. The Free Software developer

The motives of Free-Software developers are diverse. But regardless of
the motives, they generally improve the lives of Free-Software users. If
the software addresses consumer needs, Free-Software developers often
find themselves as competing with proprietary applications.


Of course, the categories are not clear-cut. But they help to address
two questions: (1) Who would benefit from the ability to host
proprietary applications on top of the open-source Genode system, and
(2) whom do we want to cater with the open-source license of Genode?

Regarding question (1), only the proprietary application vendor would
immediately benefit, but only under the condition that Genode is a
platform used by their target audience (consumers). This is of course
not the case. Hence, for an application vendor, there is no business
case for porting their applications to Genode at all. Instead,
application vendors focus on popular end-user platforms like iOS,
Android, Windows.

Regarding question (2), with Genode's open-source license, we want to
cater Free-Software users and Free-Software developers in the first
place. Acknowledging that the open-source Genode system is not a
consumer platform as is, there is no benefit in catering the interests
of proprietary application vendors with Genode's open-source license.

Please don't get me wrong. I don't dismiss consumers. I see two
principle ways of how Genode can reach popularity among consumers, by
becoming a consumer platform, or by consumers gravitating towards Free
Software. Regarding the former, I am convinced that Genode can become a
popular consumer platform only with strong commercial incentives of a
platform vendor. Should a platform vendor develop such an interest, it
would seek a commercial license. The funding obtained from the
commercial licensing would ultimately help Genode and thereby the
Free-Software community. The second direction is that consumers would
buy products that are solely based on Free Software. Personally, as a
Free-Software user, I find this prospect quite exciting.

Given this line of thinking, I hope that you agree that the ability to
host proprietary applications on top of the open-source Genode system
would not bring any tangible value. But maybe I have overlooked
something? Please don't hesitate to share your thoughts.

Regards
Norman

[Nobody III]

I'm thinking of the possibility of Genode becoming a consumer OS platform.
One benefit of Genode is that a user doesn't need to trust every single
program running on his computer. If I have to run a piece of proprietary
software, Genode would be my preferred platform. Also, for software that I
don't have to trust, I don't care as much whether it's proprietary. I would
prefer that Adobe and Autodesk port their software to Genode, especially
since 3D software doesn't work well in VirtualBox. I prefer free software
because it's more trustworthy, but I still use some proprietary software
(e.g. Google Chrome with Flash Player).

On Dec 17, 2016 8:38 AM, "Norman Feske" <***@genode-labs.com>
wrote:

Hello Ben,

Post by Nobody III
Am I correct that software that doesn't link directly to any AGPLv3 code
(e.g. code that just uses libc) is okay to have proprietary licenses?

this is not correct because the proprietary code would still linked to
Genode in addition to the libc.

Post by Nobody III
That seems to be the logical interpretation, and probably the most
beneficial, as it wouldn't discourage companies from porting their
software to Genode.

This statement is interesting because it raises the question of the
motives and goals behind Genode. What does "most beneficial" mean?
Beneficial to whom? Let me try to look at this question from different
perspectives.


1. The Free Software user

For an end user who consciously uses a Free Software ecosystem,
proprietary applications are not interesting because they restrict the
freedom of the user. Frankly speaking, I am an example of such a user. I
have not touched proprietary applications on my computer since several
years. But I vividly remember the inconvenience of using opaque
installers, the lack of security updates, the inability to fix bugs, or
the suspicion about backdoors and vulnerabilities introduced by such
applications. The argument that an operating system would be useless
without proprietary applications was probably valid 15 years ago. Today,
the Free Software world is so strong and diverse that this argument does
not hold anymore.


2. The consumer

Many end users are neither aware nor interested in technical details.
They just want to get work done, browse the web, play games, or watch
movies. From the operating-system's perspective, I also see
professionals (like photographers, writers, business users) in this
category. A typical consumer uses the OS that comes pre-installed on the
device, and accepts the inherent dependency from commercial vendors. The
user does not care too much about the uppercase Freedom of software. I
am sometimes such a user. E.g., when using my portable audio player, I
just want to listen to music.


3. The proprietary application vendor

For a proprietary application vendor, the consumer (2) is a business
case. The application vendor wants to create and distribute applications
with as little costs as possible and sell them to the consumer at the
highest price possible. The latter would not be easily possible if the
application vendor published its own "intellectual property" to everyone
for free. Hence, the applications tend to stay proprietary to uphold the
business case. The application vendor has to consider expenses like
paid-for development tools, licenses of commercial libraries, or
app-store fees as cost factors. It is clear that proprietary application
vendors welcome liberally licensed open-source libraries or platforms
for hosting and distributing proprietary software at no costs.


4. The proprietary platform vendor

A vendor may use Genode as the basis of a proprietary platform, for
example an appliance designated for a specific market. But such a
platform may in principle also be targeted at the consumer mass market.
In order to use Genode as the basis of a proprietary platform, the
platform vendor obtains a commercial license of Genode. In this case,
the choice of Genode's regular open-source license is not a concern for
such a platform vendor.


5. The Free Software developer

The motives of Free-Software developers are diverse. But regardless of
the motives, they generally improve the lives of Free-Software users. If
the software addresses consumer needs, Free-Software developers often
find themselves as competing with proprietary applications.


Of course, the categories are not clear-cut. But they help to address
two questions: (1) Who would benefit from the ability to host
proprietary applications on top of the open-source Genode system, and
(2) whom do we want to cater with the open-source license of Genode?

Regarding question (1), only the proprietary application vendor would
immediately benefit, but only under the condition that Genode is a
platform used by their target audience (consumers). This is of course
not the case. Hence, for an application vendor, there is no business
case for porting their applications to Genode at all. Instead,
application vendors focus on popular end-user platforms like iOS,
Android, Windows.

Regarding question (2), with Genode's open-source license, we want to
cater Free-Software users and Free-Software developers in the first
place. Acknowledging that the open-source Genode system is not a
consumer platform as is, there is no benefit in catering the interests
of proprietary application vendors with Genode's open-source license.

Please don't get me wrong. I don't dismiss consumers. I see two
principle ways of how Genode can reach popularity among consumers, by
becoming a consumer platform, or by consumers gravitating towards Free
Software. Regarding the former, I am convinced that Genode can become a
popular consumer platform only with strong commercial incentives of a
platform vendor. Should a platform vendor develop such an interest, it
would seek a commercial license. The funding obtained from the
commercial licensing would ultimately help Genode and thereby the
Free-Software community. The second direction is that consumers would
buy products that are solely based on Free Software. Personally, as a
Free-Software user, I find this prospect quite exciting.

Given this line of thinking, I hope that you agree that the ability to
host proprietary applications on top of the open-source Genode system
would not bring any tangible value. But maybe I have overlooked
something? Please don't hesitate to share your thoughts.

Regards
Norman

--
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
GeschÀftsfÌhrer: Dr.-Ing. Norman Feske, Christian Helmuth

------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[ILYA Khlopotov]

Hi Norman,

I am also sharing Nobody's POV.
If proprietary vendors are unable to run their code. the genode has no interest to them. even if it would gain popularity and became most used OS we will not see native Skype or Photoshop.

Everyone understands your point and respects your licensing choice. Would it be possible to have the kernel level components stay free software but standard library to become more proprietary friendly.

in Linux for example libc is LGPL not GPL.

Best regards,
ILYA

Post by Nobody III
I'm thinking of the possibility of Genode becoming a consumer OS platform.
One benefit of Genode is that a user doesn't need to trust every single
program running on his computer. If I have to run a piece of
proprietary
software, Genode would be my preferred platform. Also, for software that I
don't have to trust, I don't care as much whether it's proprietary. I would
prefer that Adobe and Autodesk port their software to Genode,
especially
since 3D software doesn't work well in VirtualBox. I prefer free software
because it's more trustworthy, but I still use some proprietary
software
(e.g. Google Chrome with Flash Player).
Hello Ben,

Post by Nobody III
Am I correct that software that doesn't link directly to any AGPLv3

code

Post by Nobody III
(e.g. code that just uses libc) is okay to have proprietary licenses?

this is not correct because the proprietary code would still linked to
Genode in addition to the libc.

Post by Nobody III
That seems to be the logical interpretation, and probably the most
beneficial, as it wouldn't discourage companies from porting their
software to Genode.

This statement is interesting because it raises the question of the
motives and goals behind Genode. What does "most beneficial" mean?
Beneficial to whom? Let me try to look at this question from different
perspectives.
1. The Free Software user
For an end user who consciously uses a Free Software ecosystem,
proprietary applications are not interesting because they restrict the
freedom of the user. Frankly speaking, I am an example of such a user. I
have not touched proprietary applications on my computer since several
years. But I vividly remember the inconvenience of using opaque
installers, the lack of security updates, the inability to fix bugs, or
the suspicion about backdoors and vulnerabilities introduced by such
applications. The argument that an operating system would be useless
without proprietary applications was probably valid 15 years ago. Today,
the Free Software world is so strong and diverse that this argument does
not hold anymore.
2. The consumer
Many end users are neither aware nor interested in technical details.
They just want to get work done, browse the web, play games, or watch
movies. From the operating-system's perspective, I also see
professionals (like photographers, writers, business users) in this
category. A typical consumer uses the OS that comes pre-installed on the
device, and accepts the inherent dependency from commercial vendors. The
user does not care too much about the uppercase Freedom of software. I
am sometimes such a user. E.g., when using my portable audio player, I
just want to listen to music.
3. The proprietary application vendor
For a proprietary application vendor, the consumer (2) is a business
case. The application vendor wants to create and distribute
applications
with as little costs as possible and sell them to the consumer at the
highest price possible. The latter would not be easily possible if the
application vendor published its own "intellectual property" to
everyone
for free. Hence, the applications tend to stay proprietary to uphold the
business case. The application vendor has to consider expenses like
paid-for development tools, licenses of commercial libraries, or
app-store fees as cost factors. It is clear that proprietary
application
vendors welcome liberally licensed open-source libraries or platforms
for hosting and distributing proprietary software at no costs.
4. The proprietary platform vendor
A vendor may use Genode as the basis of a proprietary platform, for
example an appliance designated for a specific market. But such a
platform may in principle also be targeted at the consumer mass market.
In order to use Genode as the basis of a proprietary platform, the
platform vendor obtains a commercial license of Genode. In this case,
the choice of Genode's regular open-source license is not a concern for
such a platform vendor.
5. The Free Software developer
The motives of Free-Software developers are diverse. But regardless of
the motives, they generally improve the lives of Free-Software users. If
the software addresses consumer needs, Free-Software developers often
find themselves as competing with proprietary applications.
Of course, the categories are not clear-cut. But they help to address
two questions: (1) Who would benefit from the ability to host
proprietary applications on top of the open-source Genode system, and
(2) whom do we want to cater with the open-source license of Genode?
Regarding question (1), only the proprietary application vendor would
immediately benefit, but only under the condition that Genode is a
platform used by their target audience (consumers). This is of course
not the case. Hence, for an application vendor, there is no business
case for porting their applications to Genode at all. Instead,
application vendors focus on popular end-user platforms like iOS,
Android, Windows.
Regarding question (2), with Genode's open-source license, we want to
cater Free-Software users and Free-Software developers in the first
place. Acknowledging that the open-source Genode system is not a
consumer platform as is, there is no benefit in catering the interests
of proprietary application vendors with Genode's open-source license.
Please don't get me wrong. I don't dismiss consumers. I see two
principle ways of how Genode can reach popularity among consumers, by
becoming a consumer platform, or by consumers gravitating towards Free
Software. Regarding the former, I am convinced that Genode can become a
popular consumer platform only with strong commercial incentives of a
platform vendor. Should a platform vendor develop such an interest, it
would seek a commercial license. The funding obtained from the
commercial licensing would ultimately help Genode and thereby the
Free-Software community. The second direction is that consumers would
buy products that are solely based on Free Software. Personally, as a
Free-Software user, I find this prospect quite exciting.
Given this line of thinking, I hope that you agree that the ability to
host proprietary applications on top of the open-source Genode system
would not bring any tangible value. But maybe I have overlooked
something? Please don't hesitate to share your thoughts.
Regards
Norman
--
Dr.-Ing. Norman Feske
Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
GeschÀftsfÌhrer: Dr.-Ing. Norman Feske, Christian Helmuth
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main
------------------------------------------------------------------------
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
------------------------------------------------------------------------
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main

[Vasily A. Sartakov]

A consumer platform vendor wants to create a platform based on the
open-source Genode system. That is, the base system is AGPLv3 and all
drivers and the software stack are open. Still the vendor wants to
create a distribution channel for proprietary applications (an app
store) or other digital goods (games, movies). In this case, the vendor
could seek an exemption from the AGPLv3 for its app-store application in
exchange for letting Genode Labs participate in the commercial success
of the consumer platform. Under this model, Genode would indirectly
benefit from the proprietary application vendors. So an exemption is
granted for a tangible benefit for Genode.
As another example, for some software the source code may got lost. So
it becomes technically impossible to comply with the AGPLv3. The ability
to combine such software (e.g., "abandonware") with Genode should not
pose a problem.

there is a common practice for hardware/software complex developments in Linux world. Simple example: Ebooks from SONY. The SONY uses Linux kernel and minimal runtime for ebook boostrapping. On top of this open source software, Sony develops own proprietary software (in fact, based on java). In accordance with licenses, SONY publishes all sources, except, of course, own proprietary. This is very simple and profitable. The community could have an ability to run own software instead of proprietary, SONY decreases costs and significant decreases time-to-market, license trolls do not have an effect on the SONY. Everyone is happy.

[Jookia]

Post by Norman Feske
Hello Ilya,

Jookia here, not a direct reply.

Post by Norman Feske
the discussion has largely deviated from the original topic, which is
Genode's move from GPLv2 to AGPLv3. Please note that the relationship of
proprietary software and Genode remains untouched by Genode's license
change.
Even though I am little afraid of the discussion getting further
derailed, I don't want to leave your remarks unanswered.

Apologies for starting this derail. I just want to say that I truly admire the
extent Genode has taken to push for free software, and it's changed my thinking
in a lot of it. I think actions speak louder than words, but it can be confusing
when a lot of the times dual-licensing is used against the community for
companies to effectively get free developers.

My primary concern is that I don't want to see a situation where it turns out
Genode Labs and the community are at odds over a fork or distribution that takes
off but can't be dual-licensed or otherwise enter this business model.

Post by Norman Feske
Regards
Norman

Jookia.

[Alexander Senier]

Thanks, Norman, for that well-structured review of the proprietary software issue.

One aspect came to mind that I don't see covered, thought. One some platforms, proprietary device drivers are mandatory even on Linux to get
certain functionality working. Think of popular 3D graphics cards as an example. The much I'd like to see open source device drivers all over
the place (as yourself, I belong to the pure-OSS users category), I'm pessimistic about that. Especially for complex 3D graphics we won't see
major vendors release open source driver, let alone proper documentation.

Still, it would be highly beneficial for any kind of user to have these proprietary binary-only drivers on Genode instead of other platforms. In
contrast to Linux kernel modules, we can run them as unprivileged users space process, set up IO virtualization etc.

(How) can proprietary binary-only drivers be included in the open source version of Genode under the new license scheme?

Cheers,
Alex

Post by Norman Feske
Given this line of thinking, I hope that you agree that the ability to
host proprietary applications on top of the open-source Genode system
would not bring any tangible value. But maybe I have overlooked
something? Please don't hesitate to share your thoughts.

[Josef Söntgen]

Hi Alexander,

Post by Alexander Senier
One aspect came to mind that I don't see covered, thought. One some
platforms, proprietary device drivers are mandatory even on Linux to
get certain functionality working. Think of popular 3D graphics cards
as an example. The much I'd like to see open source device drivers all
over the place (as yourself, I belong to the pure-OSS users category),
I'm pessimistic about that. Especially for complex 3D graphics we
won't see major vendors release open source driver, let alone proper
documentation.

Do not use this platform then. I know, easier said than done but you
have to start somewhere and in the end it is actually that simple. Not
buying hardware that requires proprietary device drivers is certainly a
start and may point vendors into the “right” direction by showing that
customers care about those things. (I fear this is the perfect topic to
de-rail the thread so I am going to stop here ☺)

Post by Alexander Senier
Still, it would be highly beneficial for any kind of user to have
these proprietary binary-only drivers on Genode instead of other
platforms. In contrast to Linux kernel modules, we can run them as
unprivileged users space process, set up IO virtualization etc.

That would be beneficial indeed. However, before vendors care about
other systems, there has to be an incentive. For example look at
Sailfish OS — they have to wrap Android user space drivers to use them
on there glibc based system because nowadays Android is the only system
a certain group of vendors cares about. My best guess is that Android
currently is the only relevant market to them. So what would be the
incentive to provide proprietary drivers for Genode in the first place?
For better or worse I do not see any and a Genode “end user” presumably
does not care much about proprietary drivers anyway. At least that is
what I assume given the fact the current Genode “end users”, according
to my perception, value having a open/free/libre/whatever system.

Now a user of the Genode framework, as in someone who builds a system or
rather a product with Genode, may care about having support for a
certain piece of hardware where only a proprietary binary-only driver is
provided by the vendor. But again, the vendor will not provide the
driver for Genode out of the blue without a given incentive. In this
case the user can pay the vendor to provide the driver (and also has to
pay for future updates). If it is a proprietary product there is already
a commercial Genode license involved and everything is fine. If it is a
non-proprietary product, that obviously is a problem because the binary
only driver may not be used (the most fitting example that comes to my
mind is someone who wants to use the open-source version of Genode in an
automotive context using NVidias Terga Drive platform and has to hire
NVidia to port their binary-only driver to Genode).

That being said, in any case, I do not think that the license itself
is a reason that prevents people from using Genode.

Post by Alexander Senier
(How) can proprietary binary-only drivers be included in the open
source version of Genode under the new license scheme?

No but that was also the case under the old license — switching to
AGPLv3 does not change anything in that regard.

Given that, the only example I can come up with from my personal
requirements would be GPU and to some extent GSM/LTE drivers (a well
documented smartphone SoC for running Genode would be great). In the
former case I would mostly need them to run proprietary binary-only
software that is not available for Genode anyway and again I see no
incentive for publishers to change that for now, even if the license
would permit it. We probably will never have a native Netflix client on
Genode either as long as it depends on proprietary binary-only DRM
component. I can, however, use Chrome on Linux in a VM on Genode which
works well enough. So for me do not having proprietary software is a
non-issue and quite frankly I would rather not add another exception to
the license prematurely because “it would be nice to have the chance of
having XY on Genode”. In the past nobody cared about not having
proprietary software on Genode but rather some people cared about being
not able to use open source software because of the missing exceptions
for other open source licenses.

I probably see the matter to strict but for me Genode as a project
first and foremost follows the open-source or rather free software
values which is made clear by the choice of the license and proprietary
sofware (e.g. by using a commercial license) is only used to fund the
development. Being open source benefits “any kind of user” of a Genode
system in the long run.


Regards
Josef

[Jookia]

Post by Josef Söntgen
Now a user of the Genode framework, as in someone who builds a system or
rather a product with Genode, may care about having support for a
certain piece of hardware where only a proprietary binary-only driver is
provided by the vendor. But again, the vendor will not provide the
driver for Genode out of the blue without a given incentive. In this
case the user can pay the vendor to provide the driver (and also has to
pay for future updates). If it is a proprietary product there is already
a commercial Genode license involved and everything is fine. If it is a
non-proprietary product, that obviously is a problem because the binary
only driver may not be used (the most fitting example that comes to my
mind is someone who wants to use the open-source version of Genode in an
automotive context using NVidias Terga Drive platform and has to hire
NVidia to port their binary-only driver to Genode).

Shouldn't the user be able to buy a product, rip the proprietary code out and
use that in their free version?

[Norman Feske]

Hello Jookia,

Post by Jookia
How will proprietary Genode distributions
use GPLv2 code from Linux or other copyleft projects, or do they just not?

under the commercial license, Genode is an ingredient of a proprietary
operating system, let's call it "Vendor OS". The Vendor OS comes with a
proprietary system library. The fact that this proprietary system
library is somehow based on Genode does not matter. The end user only
sees the Vendor OS, not Genode.

So your question can be more generally stated as "Can a proprietary
operating use GPL software?". The answer is obviously yes. E.g., before
the Linux kernel was born, GNU was primarily running on top of
proprietary Unix variants. Also, GPL software runs on top Windows OS or
other proprietary OSes.

When shipping a Vendor OS that includes GPL components, the Vendor needs
to comply with the GPL licenses of the used components. In particular,
the Vendor needs to provide the used GPL source code as well as all the
prerequisites that would be needed by the user to reproduce the binary.
(e.g., since Vendor OS is based on Genode, the most practical approach
for the Vendor to comply with the GPL would be to provide the Genode
source code that was used for building the binaries present in Vendor OS)

The interaction of GPL software with proprietary software in general is
well understood and documented by the FSF. All the established rules and
practices apply to Vendor OS. For example, whereas it would be fine to
use the Linux USB driver as a component on Vendor OS as it is a separate
program, it would not be possible for a proprietary component to
directly use the Linux TCP/IP stack because on Genode, the TCP/IP stack
is a library, not a separate program.

Does this explanation answer your question?

Regards
Norman

[ILYA Khlopotov]

hello Norman,

I am watching the GenodeOS for quite some time. A while ago I started a port of Erlang language to genode. Erlang is licensed under ASFv2. In order to compile it under GenodeOS it needs a c library.
please clarify how it would be possible to combine ASF and AGPL.

Best regards,
ILYA

Post by Norman Feske
Dear community,
with the upcoming release 17.02, we are planning to change Genode's
open-source license.
The current GPLv2 license
-------------------------
The Genode OS Framework is currently licensed under the terms of the
version 2 of the GNU General Public License. We originally picked this
* It captures the spirit of Free Software, which we deeply share with
the FSF. The license ultimately empowers the authors and the end
users of software. Genode would not exist without Free Software. It
is built on the shoulders of software like GCC, the GNU system, or
Linux. All software that we at Genode Labs develop is Free Software.
* At the time of the first Genode release, the GPLv2 was a time-tested
and widely used license.
* It enables the dual-licensing business model of Genode Labs. If
Genode is commercially leveraged for proprietary solutions, Genode
Labs benefits from the success of such products. This way, Genode
has a long-term strategy to fund its development without relying on
donations, public funding, or venture capital. We value this
independence as fundamental for the sustainability of our project.
* Adopting the same license as Linux made a lot of sense because we
are routinely reusing Linux driver code inside Genode components.
Affero General Public License
-----------------------------
The time did not stand still. The GPLv3 became widely spread and
well-understood. It rectifies several shortcomings of the GPLv2.
Furthermore, the Affero General Public License [1] closes loopholes of
the GPL license with respect to web applications. Unlike 2008 when most
applications were programs executed directly on the end user's
computer,
web applications have become predominant by now.
For Genode, we ignored the deficiencies of the GPLv2 for a long time. At
the same time, with more and more software being added to our "ports" -
the library of 3rd-party software ported to Genode - the license
compatibility question, which we tried to avoid for Linux kernel code,
arises for other 3rd-party software that is combined with Genode.
Admittedly, one reason for our hesitance was our fear of long-winded and
opinion-loaded discussions around the licensing topic. But we
ultimately
have to acknowledge that an update to a modern license and a
clarification of our stance with respect to the interoperability of
Genode with other Open-Source software is long overdue.
The AGPLv3 encapsulates exactly the spirit, which originally attracted
us to the GPL. After careful review, it makes perfect sense to use it
for Genode. The following Wikipedia article nicely explains the
https://en.wikipedia.org/wiki/Affero_General_Public_License
Addressing interoperability concerns
------------------------------------
Unlike most end-user software, which falls into a tangible category
(application, library, kernel), Genode plays a special role. Not just
because it is an operating system. But it is very unconventional at
that: It is a collection of programs (Genode components). It is also a
set of application libraries. It is also a "system library". It also
comprises a dynamic linker. It may also be the kernel (i.e., our base-hw
kernel). The lines between the categories become blurry.
For this reason, we intend to add a linking clause to Genode's version
of the AGPL license text, similar to the classpath linking exception but
restricted to software licenses that are blessed by the Open-Source
Initiative, the Free Software Foundation, or Genode Labs.
Inspired from the text of the classpath linking exception, our clause
Linking Genode code statically or dynamically with other modules
is making a combined work based on Genode. Thus, the terms and
conditions of the GNU Affero General Public License version 3
(AGPLv3) cover the whole combination.
As an "additional permission" as defined by Section 7 of the
AGPLv3, Genode Labs as the copyright holder of Genode gives you
permission to link Genode source code with "independent modules"
to produce an executable if the independent modules are licensed
under an "approved license", 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 "approved license" is a license that is officially approved as
an Open-Source license by the Open Source Initiative [1], or
listed as a Free-Software license by the Free Software Foundation
[2], or explicitly approved by Genode Labs.
An "independent module" is a module which is not derived from or
based on Genode.
If you modify Genode, you may extend this exception to your
version of Genode, but you are not obliged to do so. If you do not
wish to do so, delete this exception statement from your version.
[1] https://opensource.org/licenses
[2] https://www.gnu.org/licenses/license-list.en.html
With this clause in place, we want to express our consent to use Genode
in combination with other open-source software. Note, however, that -
unlike the classpath exception clause, our clause excludes the
combination of Genode with proprietary software. This is our deliberate
decision.
With Genode becoming AGPLv3, we face the question of how to integrate
3rd-party code (like GPLv2-licensed Linux device drivers) in a Genode
component. To address this concern, Genode-specific glue code that is
needed to integrate the 3rd-party code with the Genode API ("system
library") will have a license that is compatible with both the license
of the 3rd-party code and Genode's AGPLv3 as such glue code is a
derivative of both Genode and the incorporated code, e.g., the MIT
license. In line with the wording of the exception clause above, when
distributing binaries of such components, the licenses of both Genode
and the incorporated 3rd-party code must be respected.
I hope that you support our plan to relicense Genode to AGPLv3 along
with our linking exception clause. Should you have doubts about us
taking this direction, please let me know.
Best regards
Norman
--
Dr.-Ing. Norman Feske
Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
GeschÀftsfÌhrer: Dr.-Ing. Norman Feske, Christian Helmuth
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
genode-main mailing list
https://lists.sourceforge.net/lists/listinfo/genode-main

[Norman Feske]

Hello Ilya,

Post by ILYA Khlopotov
I am watching the GenodeOS for quite some time. A while ago I started a
port of Erlang language to genode.

interesting!

Post by ILYA Khlopotov
Erlang is licensed under ASFv2. In
order to compile it under GenodeOS it needs a c library.
please clarify how it would be possible to combine ASF and AGPL.

The Apache Software License v2 is compatible to AGPLv3. That means you
are in principle even allowed to copy code ASFv2 code into a AGPLv3
code. The result would be AGPLv3. You cannot, however, copy AGPLv3 code
into ASFv2 code.

That said, as a matter of license hygiene, mixing code of different
licenses in the same source code files should be avoided whenever
possible. Even if licenses are compatible, such practice is generally
not in the interest of the original author. E.g., imagine an author who
once published some code under a liberal (MIT/BSD) license and later
rediscovers the exact code as part of a file with a strong copyleft
license. So the original author cannot legally backport bugfixes of
his/her own work into the original liberally licensed code. This would
leave a bitter taste.

Combining ASFv2 code with AGPLv3 code as "independent modules" is not a
problem at all. ASFv2 is both approved by OSI and listed as a Free
Software license by the FSF. As expressed by our linking exception
clause, we have absolutely no concern about combining such code with Genode.

Was I able to clarify your question?

Cheers
Norman