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

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

On Dec 16, 2016 6:43 AM, "Jookia" <166291 at ...9...> wrote:

> On Fri, Dec 16, 2016 at 12:27:59PM +0100, Norman Feske wrote:
> > Hello Jookia,
>
> Hi again :)
>
> > > 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
> >
> > > 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?
>
> 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?
>
> > Thank you for your scrutiny!
>
> No problem.
>
> > 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
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20161217/e12bee46/attachment.html>