Licensing issues with Scour (aka 'Optimized SVG' output)
Hi all,
I'm posting here today hoping that we can finally resolve some licensing issues which recently emerged regarding the Scour extension for Inkscape (also know as 'Optimized SVG' output).
I'll try to summarize the issue as good as possible so everybody is up to speed:
* Right now we bundle an old version of Scour that is dual-licensed with Apache 2.0 license and GPLv2+. This dual licensing was only introduced in a very recent commit [1] when the original author Jeff Schiller agreed to re-license his code under the terms of GPLv2+ after license issues in Inkscape were brought up in a previous discussion [2]. However at this point there were multiple contributions to the Scour codebase by other authors who did not accept to re-license their contributions. This is why the re-licensing is likely to be void and the the current maintainer of Scour (Tobias Oberstein) decided not to apply the dual-licensing when switching over to GitHub with the project [3]. * I recently updated the Scour extension for Inkscape and want to merge these changes [4]. Obviously I followed Tobias Obersteins decision not to apply the dual-licensing, so the new version only has the Apache 2.0 License. * The open question now is: Can we bundle the Scour code with Inkscape and how to we do it?
In my opinion this should not be a problem since Scour is an external module that is *indepentent* from Inkscape, e.g. license incompatibilities do not play a role here which is also the opinion of Tobias Oberstein (see [5] for details and references). Also most project members seem to agree (see comments in the merge request [4])
However If we don't want to follow this reasoning we have to decide on alternatives (especially since the code currently in trunk might well have an invalid license).
I hope we can once and for all resolve this issue!
Best Regards, Eduard
[1] http://bazaar.launchpad.net/~scouring/scour/trunk/revision/222 [2] https://sourceforge.net/p/inkscape/mailman/message/32342425/ [3] https://github.com/codedread/scour [4] https://code.launchpad.net/~eduard-braun2/inkscape/scour/+merge/278387 [5] https://github.com/codedread/scour/issues/7
Scour is not a derivative work of Inkscape, and neither is Inkscape a derivative work of Scour (no code is shared between the two). Their licenses are completely independent, and not need to be compatible. On Jan 9, 2016 11:24, "Eduard Braun" <Eduard.Braun2@...173...> wrote:
Hi all,
I'm posting here today hoping that we can finally resolve some licensing issues which recently emerged regarding the Scour extension for Inkscape (also know as 'Optimized SVG' output).
I'll try to summarize the issue as good as possible so everybody is up to speed:
- Right now we bundle an old version of Scour that is dual-licensed
with Apache 2.0 license and GPLv2+. This dual licensing was only introduced in a very recent commit [1] when the original author Jeff Schiller agreed to re-license his code under the terms of GPLv2+ after license issues in Inkscape were brought up in a previous discussion [2]. However at this point there were multiple contributions to the Scour codebase by other authors who did not accept to re-license their contributions. This is why the re-licensing is likely to be void and the the current maintainer of Scour (Tobias Oberstein) decided not to apply the dual-licensing when switching over to GitHub with the project [3].
- I recently updated the Scour extension for Inkscape and want to
merge these changes [4]. Obviously I followed Tobias Obersteins decision not to apply the dual-licensing, so the new version only has the Apache 2.0 License.
- The open question now is: Can we bundle the Scour code with Inkscape
and how to we do it?
In my opinion this should not be a problem since Scour is an external module that is *indepentent* from Inkscape, e.g. license incompatibilities do not play a role here which is also the opinion of Tobias Oberstein (see [5] for details and references). Also most project members seem to agree (see comments in the merge request [4])
However If we don't want to follow this reasoning we have to decide on alternatives (especially since the code currently in trunk might well have an invalid license).
I hope we can once and for all resolve this issue!
Best Regards, Eduard
[1] http://bazaar.launchpad.net/~scouring/scour/trunk/revision/222 [2] https://sourceforge.net/p/inkscape/mailman/message/32342425/ [3] https://github.com/codedread/scour [4] https://code.launchpad.net/~eduard-braun2/inkscape/scour/+merge/278387 [5] https://github.com/codedread/scour/issues/7
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Eduard,
That's very disappointing to hear the lack of GPL support.
So the question for scour is:
* Do any scour header files, or other code files end up in a binary? No, it's python as long as it's separate. * Do we ship the scour package as part of the same package? Yes
So we're not in violation of copyright[1], but Fedora, Debian and other linux distros will be unhappy. They would prefer it if the module was kept outside of the repository and final packages and then simply required in at install time.
We could still remove the code from our repository (which I would heartily support) and have it as dependency instead. Just make sure that scour is available or we will have to make it available to the various repositories for developers.
Martin Owens
1. IANAL, It never hurts to get a legal opinion from a real lawyer.
On Sat, 2016-01-09 at 20:23 +0100, Eduard Braun wrote:
Hi all,
I'm posting here today hoping that we can finally resolve some licensing issues which recently emerged regarding the Scour extension for Inkscape (also know as 'Optimized SVG' output).
I'll try to summarize the issue as good as possible so everybody is up to speed: * Right now we bundle an old version of Scour that is dual-licensed with Apache 2.0 license and GPLv2+. This dual licensing was only introduced in a very recent commit [1] when the original author Jeff Schiller agreed to re-license his code under the terms of GPLv2+ after license issues in Inkscape were brought up in a previous discussion [2]. However at this point there were multiple contributions to the Scour codebase by other authors who did not accept to re-license their contributions. This is why the re-licensing is likely to be void and the the current maintainer of Scour (Tobias Oberstein) decided not to apply the dual-licensing when switching over to GitHub with the project [3]. * I recently updated the Scour extension for Inkscape and want to merge these changes [4]. Obviously I followed Tobias Obersteins decision not to apply the dual-licensing, so the new version only has the Apache 2.0 License. * The open question now is: Can we bundle the Scour code with Inkscape and how to we do it?
In my opinion this should not be a problem since Scour is an external module that is *indepentent* from Inkscape, e.g. license incompatibilities do not play a role here which is also the opinion of Tobias Oberstein (see [5] for details and references). Also most project members seem to agree (see comments in the merge request [4])
However If we don't want to follow this reasoning we have to decide on alternatives (especially since the code currently in trunk might well have an invalid license).
I hope we can once and for all resolve this issue!
Best Regards, Eduard
[1] http://bazaar.launchpad.net/~scouring/scour/trunk/revision/222 [2] https://sourceforge.net/p/inkscape/mailman/message/32342425/ [3] https://github.com/codedread/scour [4] https://code.launchpad.net/~eduard-braun2/inkscape/scour/+merge/278387 [5] https://github.com/codedread/scour/issues/7
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Martin,
So we're not in violation of copyright[1], but Fedora, Debian and other linux distros will be unhappy. They would prefer it if the module was kept outside of the repository and final packages and then simply required in at install time.
What does "prefer" mean in this context? Is this a strict limitation or could we still do it in case we lack a better solution?
Regarding "requiring in" at install time I already asked in my merge request: Do we have a mechanism for that? (Sorry if that's a dumb question, but I'm not native to the Linux world) As of now Scour is available from PyPI (https://pypi.python.org/pypi/scour). Would this work? Or would we have to somehow get scour packaged for every Distro out there? Then I doubt this would be a workable solution...
Either way we'd still need a way to include Scour in Mac/Windows builds which I assume complicates the whole process even more?
We could still remove the code from our repository (which I would heartily support) and have it as dependency instead. Just make sure that scour is available or we will have to make it available to the various repositories for developers.
Could you elaborate on that? How do we "make sure that scour is available" and what would be "the various repositories for developers"?
Best Regard, Eduard Braun
On Sun, 2016-01-10 at 16:22 +0100, Eduard Braun wrote:
What does "prefer" mean in this context? Is this a strict limitation or could we still do it in case we lack a better solution?
They consider it broken. While it's unlikely inkscape would be thrown out (it's too damn useful); they are right to ask us for a single non-conflicting license for our packages.
Or would we have to somehow get scour packaged for every Distro out there? Then I doubt this would be a workable solution...
It should be available as python-scour on debian, if not then is /should/ be packaged and many packagers would help us get it packages for their system.
Either way we'd still need a way to include Scour in Mac/Windows builds which I assume complicates the whole process even more?
Of course, but it's not like we don't have other requirements included for windows and mac builds already. I'm not sure of the process, but maybe pip can be used to get the modules for those at build time.
Could you elaborate on that? How do we "make sure that scour is available" and what would be "the various repositories for developers"?
The first people to be effected will be developers. So making sure they can install it will be important. pip is a good candidate, but having it in our ppa would be very useful too.
Best Regards, Martin Owens
On 10/01/16 18:28, Martin Owens wrote:
On Sun, 2016-01-10 at 16:22 +0100, Eduard Braun wrote:
What does "prefer" mean in this context? Is this a strict limitation or could we still do it in case we lack a better solution?
They consider it broken. While it's unlikely inkscape would be thrown out (it's too damn useful); they are right to ask us for a single non-conflicting license for our packages.
Are you sure? Many Debian packages are composed of parts with different licenses. Not even the glibc has an uniform license, see /usr/share/doc/libc6/copyright on a Debian system.
That said, if Scour is useful independently from Inkscape, it is definitely a good idea to package it separately and do not bundle it with Inkscape.
Cheers, Daniele
On Sun, 2016-01-10 at 18:38 +0100, Daniele Nicolodi wrote:
Are you sure? Many Debian packages are composed of parts with different licenses. Not even the glibc has an uniform license, see /usr/share/doc/libc6/copyright on a Debian system.
Those licenses don't look like they are conflicting.
As I said, I'd welcome packaging even without the licensing issue.
On 10/01/16 20:12, Martin Owens wrote:
On Sun, 2016-01-10 at 18:38 +0100, Daniele Nicolodi wrote:
Are you sure? Many Debian packages are composed of parts with different licenses. Not even the glibc has an uniform license, see /usr/share/doc/libc6/copyright on a Debian system.
Those licenses don't look like they are conflicting.
I don't know what you mean by "conflicting" in this context. The Apache 2.0 License is an OSI approved license, and it is compatible with the GPLv3.
http://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses
Cheers, Daniele
@Martin From your answers, it seems you're clearly voting for removing Scour from Inkscape source and use it as an external package?
I'm still no friend of that, especially since Scour is not regularly packaged for any Linux distros and I don't even have the slightest idea on how these things are handled for MacOS. Yet I'm pleased to see that scour-python was just updated for Ubuntu (http://packages.ubuntu.com/search?suite=all&searchon=names&keywords=...) and Debian (https://packages.debian.org/search?keywords=python-scour).
To prevent this from hitting another dead end I'd be willing to follow through with it unless somebody has still an idea on how to solve this in a more ideal way.
Things I've done so far:
* I have modified my local copy of the Scour extension for Inkscape to be able to make use of an external Scour package that is installed on the system * I verified this solution to work on Ubuntu (in principle) * I checked how we handle Python packages on Windows: We simply include them in the devlibs (as we do with Python itself) so they will be installed with the rest of the compiled files. This works flawlessly.
In order to make the transition there are however some open questions:
* The scour-python package was only updated to the latest version (which is 0.32) for unstable branches as you can see when following the links provided above. Stable branches still have 0.26-3 which is over 4 years old! Will those packets be upgraded in a timely manner or does this mean people using those distros are stuck? Just to be clear: Such old versions won't be compatible with the Inkscape extension (Scour wasn't even a real python module back then!). I only got it working by installing the package from xenial in my Ubuntu vivid (therefore the conditional above) * What about Scour packages for MacOS? Where does one even get those and are those bundled with the installer (similar to Windows) or would those need to be added as requirements too (as in Linux)? I'm totally clueless here...
Also I'd need some help on certain points:
* How does one add a package requirement for Linux builds? Can somebody support me with this part in case we go through with it? * Same question for MacOS. While I have mediocre knowledge of Linux I have never even used MacOS, so here I have no idea what to do.
Best Regards, Eduard
Am 10.01.2016 um 18:28 schrieb Martin Owens:
On Sun, 2016-01-10 at 16:22 +0100, Eduard Braun wrote:
What does "prefer" mean in this context? Is this a strict limitation or could we still do it in case we lack a better solution?
They consider it broken. While it's unlikely inkscape would be thrown out (it's too damn useful); they are right to ask us for a single non-conflicting license for our packages.
Or would we have to somehow get scour packaged for every Distro out there? Then I doubt this would be a workable solution...
It should be available as python-scour on debian, if not then is /should/ be packaged and many packagers would help us get it packages for their system.
Either way we'd still need a way to include Scour in Mac/Windows builds which I assume complicates the whole process even more?
Of course, but it's not like we don't have other requirements included for windows and mac builds already. I'm not sure of the process, but maybe pip can be used to get the modules for those at build time.
Could you elaborate on that? How do we "make sure that scour is available" and what would be "the various repositories for developers"?
The first people to be effected will be developers. So making sure they can install it will be important. pip is a good candidate, but having it in our ppa would be very useful too.
Best Regards, Martin Owens
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 2016-01-11 23:15 (+0100), Eduard Braun wrote:
In order to make the transition there are however some open questions:
(...)
- What about Scour packages for MacOS? Where does one even get those and are those bundled with the installer (similar to Windows) or would those need to be added as requirements too (as in Linux)? I'm totally clueless here...
I will take a look at Inkscape's osx packaging scripts, once you share the latest version of the extension proposed to be bundled with future Inkscape releases.
At this stage I assume that like on Windows, we would include the 'scour' and 'six' python module in the official Inkscape package for OS X, at least for the 64bit builds which rely on Python 2.7 as provided by the OS.
AFAIK there is no port in MacPorts yet for the new scour package hosted at PyPI, so I'd write a one (unless scour does some unusual stuff during setup, this should not be difficult, at least for Python 2.7), and add it for now to the custom ports we maintain in the packaging/macosx directory: https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head:/packag...
Also I'd need some help on certain points:
(...)
- Same question for MacOS. While I have mediocre knowledge of Linux I have never even used MacOS, so here I have no idea what to do.
Once we have an agreed-upon (in general) and tested (with packaging) solution, I would add the new dependency for the additional python modules (py27-scour, py27-six) to the custom port we use for the dependencies of official Inkscape packages for OS X: https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/packagi...
OS X package managers like MacPorts, Fink and homebrew which offer Inkscape ports handle dependencies themselves (we don't provide specific lists to them).
Regards, V
On 2016-01-12 24:19 (+0100), su_v wrote:
On 2016-01-11 23:15 (+0100), Eduard Braun wrote:
In order to make the transition there are however some open questions:
(...)
- What about Scour packages for MacOS? Where does one even get those and are those bundled with the installer (similar to Windows) or would those need to be added as requirements too (as in Linux)? I'm totally clueless here...
I will take a look at Inkscape's osx packaging scripts, once you share the latest version of the extension proposed to be bundled with future Inkscape releases.
At this stage I assume that like on Windows, we would include the 'scour' and 'six' python module in the official Inkscape package for OS X, at least for the 64bit builds which rely on Python 2.7 as provided by the OS.
AFAIK there is no port in MacPorts yet for the new scour package hosted at PyPI, so I'd write a one (unless scour does some unusual stuff during setup, this should not be difficult, at least for Python 2.7), and add it for now to the custom ports we maintain in the packaging/macosx directory: https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head:/packag...
The MacPorts port for scour is done [1], and a trac ticket for new port submission in MacPorts has been filed [2], too.
Scour 0.32 for Python 2.7 is now installed locally in the OS X build environment I use for testing Inkscape trunk builds as well as for creating the 64bit Inkscape package for OS X - ready for any tests as needed (waiting for an updated merge proposal now, with a version of the extension which loads scour as external module).
Regards, V
[1] The osx packaging scripts in inkscape trunk will be updated as needed _after_ the new scour extension was merged. For now, I keep the new port for scour in my personal port repo: http://bazaar.launchpad.net/~suv-lp/+junk/inkscape-osx-build-env/files/head:... [2] MacPorts ticket for scour @0.32 port submission: https://trac.macports.org/ticket/50301
Great!
Then I'll get going and provide an updated Scour extensions as soon as possible (hopefully this evening).
It's ready in principle but I want to add some additional checks for the Scour module with a descriptive error message in case the Scour module is not available on the System.
Regards, Eduard
Am 12.01.2016 um 11:55 schrieb su_v:
The MacPorts port for scour is done [1], and a trac ticket for new port submission in MacPorts has been filed [2], too.
Scour 0.32 for Python 2.7 is now installed locally in the OS X build environment I use for testing Inkscape trunk builds as well as for creating the 64bit Inkscape package for OS X - ready for any tests as needed (waiting for an updated merge proposal now, with a version of the extension which loads scour as external module).
Regards, V
[1] The osx packaging scripts in inkscape trunk will be updated as needed _after_ the new scour extension was merged. For now, I keep the new port for scour in my personal port repo: http://bazaar.launchpad.net/~suv-lp/+junk/inkscape-osx-build-env/files/head:... [2] MacPorts ticket for scour @0.32 port submission: https://trac.macports.org/ticket/50301
So, here we go: https://code.launchpad.net/~eduard-braun2/inkscape/scour2/+merge/282391
For those who already reviewed my previous merge request [1]: The new one is mostly identical except splitting of the scour module itself and adding some additional checks to verify if the needed modules are actually available.
Regards, Eduard
[1] https://code.launchpad.net/~eduard-braun2/inkscape/scour/+merge/278387
Am 12.01.2016 um 12:04 schrieb Eduard Braun:
Great!
Then I'll get going and provide an updated Scour extensions as soon as possible (hopefully this evening).
It's ready in principle but I want to add some additional checks for the Scour module with a descriptive error message in case the Scour module is not available on the System.
Regards, Eduard
Am 12.01.2016 um 11:55 schrieb su_v:
The MacPorts port for scour is done [1], and a trac ticket for new port submission in MacPorts has been filed [2], too.
Scour 0.32 for Python 2.7 is now installed locally in the OS X build environment I use for testing Inkscape trunk builds as well as for creating the 64bit Inkscape package for OS X - ready for any tests as needed (waiting for an updated merge proposal now, with a version of the extension which loads scour as external module).
Regards, V
[1] The osx packaging scripts in inkscape trunk will be updated as needed _after_ the new scour extension was merged. For now, I keep the new port for scour in my personal port repo: http://bazaar.launchpad.net/~suv-lp/+junk/inkscape-osx-build-env/files/head:... [2] MacPorts ticket for scour @0.32 port submission: https://trac.macports.org/ticket/50301
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Wed, 2016-01-13 at 00:07 +0100, Eduard Braun wrote:
So, here we go: https://code.launchpad.net/~eduard-braun2/inkscape/scour2/+merge/282391
For those who already reviewed my previous merge request [1]: The new one is mostly identical except splitting of the scour module itself and adding some additional checks to verify if the needed modules are actually available.
Thanks Eduard for your help, this helps move the scour issue forwards.
Martin,
participants (5)
-
Daniele Nicolodi -
Eduard Braun -
Krzysztof Kosiński -
Martin Owens -
su_v