Licensing Issue #563
Comments
|
Having a copy of the Fizzler sources in the SVG library is perhaps not the best way to go and might indeed be a problem. I'm not even sure if we mention the Fizzler component anywhere, same goes for the ExCss code that is also included in the External folder. I believe the LGPL might give a bit more room to use the component in the SVG project, so we should try to match the LGPL at least (GPL is more restrictive so preferably we should go for the LGPL). A quick research learned me that as long as you provide the sources and license (which we can) and attribute the author/original project (which we should) you can include it in your application and you are not required to release your other code (yours or the SVG code) under the same license. It gets more difficult if the code cannot be easily separated (the LGPL source is altered to communicate with SVG sources or your sources, that might require you to license those parts as LGPL too). Many applications use these kind of components and often you see these mentioned in the about/splash dialogs or documentation including their license. My guess is the safest bet is to extract the libs in the external folder to sub-projects in the SVG solution and compile them to separate binaries with their own licensing (and include this information in the SVG distribution). Another option is to reference the projects as NuGet packages, this will steer us more away from any legal complications. Obligatory "I am not a lawyer", but the above is my understanding. I'm not sure if anybody else is willing or able to do some more research (or is comfortable with this subject), but if you want I can do some more research next week. I think it's very interesting (and good) that you found this license issue and I am curious on how to cope with this. |
|
https://opensource.org/licenses/LGPL-3.0
This means that we can put any license on our code if we allow people to replace the Library (in this case the Fizzler library) and not obstruct access to the code. Not obstructing is done by having the sources available, the replacement part might need some attention. Based on this and some other reading I think we should move the Fizzler code into a separate assembly and bundle that with a separate license file and make a mention in the documentation that we use this library (which in my opinion is also fair to the authors of that project). If we allow users to replace the assembly with their own rolled version I suppose we are in the clear. Is this something that is feasible? This might mean that we not only provide the SVG.dll but also provide the two external libraries with their own dll. This might also bring an advantage, because developers already using the given libraries will only have a single copy in their application of these libraries since there is no longer a copy embedded in the SVG library. |
|
@gvheertum - thanks for digging into this. I actually hadn't noticed before that there is code with another license in here, and I think your suggestions are quite sensible (e.g. bundling the external libraries into extra assemblies, and mention them, together with their license, in the license text). |
|
@mrbean-bremen No problem, this topic directly caught my attention. I also never noticed the external components, perhaps because they are put in a separate folder and are not change heavy. Also the ExCss was in the SVG namespace which also obfuscated the fact that it's an external component a bit more). This topic had my attention since I had to do the license dance in the past for business purposes, so this directly stood out to me. The sources on internet are a bit "confusing" with regard to licensing for static linking or including copies of code in your application, but the common opinion seems to be that it's safer to include it as linked (and thus replaceable) component. The problem is that the licensing issues are often on the point of derivative work and the definition of derivative can be quite ambiguous for a lot of people (if you include a copy, is it a derivative, and what if you inherit from the class, etc). And law-speak can be a bit intimidating for a non-law-person, especially if it's not your native language. I'll see if I can do some more research next week, because it's still not 100% "clear" to me (and somehow this is within my interests so I want to get the full story). Hopefully I can find some legal statements written by lawyers/experts, because most information is prefixed with the well known IAmNotALawyer abbreviation. With regard to the changes: With regard to ExCss, this also seems to be a GitHub project (https://github.com/TylerBrinks/ExCSS), and is licensed under an MIT license and seems to also have a NuGet package available (.NET standard 1.1). For MIT you only seem to need to attribute and provide the license (did not yet do a full research, only the license text on the repo). Only thing we might need to do, is add the license/copyright on the ExCss part, since from what I see now there is no licensing information on that part in the SVG lib. But like the Fizzler repo it might be nicer to reference the project via the NuGet or also include as a separate assembly with the correct licensing, this might take away some of the possible issues. MIT allows you to do a lot more, but we might still need to find a way to handle this fully right. The good thing about referencing them as NuGet libraries is that the end-user needs to accept the license per included package (so the MS-PL for SVG, MIT for ExCSS and LGPL for Fizzler). This puts the end responsibility with the consuming party (this ofcourse is limited in a sense that we cannot just link everything an ignore underlying licenses, but LGPL and MIT allow including the packages as separate linked libraries) and no longer with the SVG team. On a side note, I think it would be nice to mention these dependent projects one way or another anyway. I think it would be a nice gesture to mention these projects, since they are helping the SVG team to build a very nice project. :) I always get happy myself when I see mentions of projects I contributed to in a list of referenced/used projects, so perhaps this also goes for these authors. |
|
On a different note: Although my walls-of-text might suggest otherwise, I am really not a lawyer 😉 Legal stuff and writing long texts is kind of a hobby 🤓 |
|
Previously, when I checked issue, I considered changing Fizzler to reference from |
|
Seems like Fizzler supports |
|
@H1Gdev, good point, I keep forgetting the 3.5 compatibility. .NET standard only works from .NET 4.5 and up (https://github.com/dotnet/standard/blob/master/docs/versions.md) so you are quite right that just referencing the package might not cut it. We could post a PR on the Fizzler repo for 3.5 compatibility (the code is that straightforwarded I don't think 3.5 compatibility won't be that much of an issue) and ask for a new Nuget after the changes have been merged. Another option could be to fork that repo (under the LGPL license) and reference that one. If needed we can pack a new Nuget (possibly with a different naming like SVG.Fizzler). This way we can keep the original authors and license. Possible changes/additions to the SVG.Fizzler package will automatically be correctly licensed and attributed. Shall I give that a try by forking and trying to get something published? @wieslawsoltes Unfortunately .NETStandard 1.0 requires .NET >= 4.5, so it will break the 3.5 compatibility (but that one also breaks my Mac workflow and I often have to remove the 3.5 target because otherwise my IDE won't work with the SVG lib). I think we can discuss dropping 3.5 support in the future, but that is something I cannot decide. |
I think that would be a great help. It would be easier to drop 3.5, of course, but given that it still will be supported for a few years, that is probably not a good idea. |
|
@mrbean-bremen, I'll see what I can do. Will be continued. Thanks for looking up the support-cycle for .NET 3.5, I did not expect it to be supported until 2023 in the mainstream (and 2028 extended). I agree that dropping the support would not be a viable option for now. |
|
.Net has various frameworks and versions, so it is difficult to maintain compatibility... 😫 |
|
Well, other options are not being discussed so I will try to suggest some here:
These could reduce integration issues for projects already using this library. |
|
@paulushub, you are right we directly seemed to jump to keeping the license and isolate the component. Regarding you suggestions:
I think the cleanest option is to isolate the component and refer to that isolated component, this allows others to also replace the given component. Bundling the components under their own license will not be an issue going forward. The ExCss is less of a problem, but from a personal view I would also suggest putting it in a different package and license that package under the corresponding license and attribute the original authors. Having copies of code without any attribution (regardless whether required by the license) feels a bit "meh" to me. I also kinda dislike having copies of publicly available libraries in another library, because this means duplication and will cut you of from updates/patches of that code (since the copy will completely obfuscate the relation/connection). So going forward I think removing the external copies might be the safest, nicest and most sustainable option. But then again, that is just my humble opinion and I am not one to make these decisions for the SVG team. |
|
Fizzler 1.0 supports .NET Framework 3.5 (even 2.0!) so if you want to take a binary dependency via the NuGet package then you should be good with that version. You will have nothing to gain by using the absolute latest version of the package. Versions that came after 1.0 dropped support for .NET Framework 2.0 (in 1.1) and .NET Framework 3.5 (in 1.2) but there were no code changes or new features introduced otherwise. The primary reason for dropping support was to ease my own burden by avoiding build matrix complexity while waiting for tooling to mature. At the same time, I felt that the .NET Framework 3.5 target could always be added back later and maintained in a 1.x branch even if the project moves ahead in an incompatible way. Source-embedding scenarios (like this one) are getting more and more impractical to support with C# moving quicker as a language. It means that if Fizzler wants to, for example, start using C# 8 then it will probably create an even bigger issue for an embedding project (such as this one) that may not be at liberty to do the same. Taking a dependency package therefore affords more flexibility in the longer run.
I'd like to think mature. 😉
Kudos for the attitude and thanks to everyone taking the time to pay attention to the details of the license. It wasn't chosen willy-nilly or without thought but it wasn't chosen to be a hindrance or a headache either. LGPL is fairly liberal. |
I perfectly understand your position. There are many reasons one will kept a separate copy of third-party libraries. As already coming up in the discussions, the third-party library might break compatibility especially with .NET, where programmers are easily crazy about using the latest syntax sugar! Keeping a local copy itself is not an issue but the third-party libraries must be acknowledged. My interest in this project was because it is a single small dll, but I was curious about how current the third-party libraries are, leading me to the license issue. My own SVG library supports GDI+, WPF and will soon expand to support SkiaSharp etc. |
|
@atifaziz, thanks for chiming in 😄
So maybe I'll try to make a core-compatible version of Fizzler 1.0.0 and publish that one. Thanks for warning us that using a newer version will gain us nothing, so I guess making 1.0.0 working on Core might be our best bet for now.
True, unless you are moving between the various .net "types". Moving between versions within the same type of framework (e.g. 3.5 to 4.5) the packages most likely will not break if they stay on the older version. The SVG project recently did a migration to make the whole package .NET Core compatible (and working on Linux/Mac), so that means that if we had used the 3.5 package we kind of had a compatibility issue.
Hahaha, that's what I meant, couldn't come up with the right word. No disrespect, but just unfortunate wording 😉
True, and I think it'll be no problem to link with that license. And I think that if we make changes to that part of the sources there is no issue with putting them under the same LGPL license. |
Good point, but that needs "proof" etc. Also the author has to make sure that the waiver is limited to this project and not derivatives, otherwise the MS-PL will grant full use of the newly embedded sources (and kinda makes the Fizzler component available for everybody under a MS-PL license if not worded/described correctly).
Isn't the credit part the also not part of this issue (at least for me it is). Rewriting the logic might also involve re-testing some of the code (and if it's not under test, create new tests).
Having copies embedded in your own sources is, at least for me, not the best way to secure a copy. In the past I just forked the libraries I needed and rolled my own assemblies. By having the fork you can keep track of changes/security issues. This will remove the dependency on the original author for updates and will remove the risks that might occur if the packages are somehow delisted. You can also get the forked project linked into your own solution (for easier reference), so I guess there are plenty technical solutions to fix this. But I don't think that's the problem here since everybody participating has some way to work with this in his toolbelt 😉 This is a interesting subject on it's own, because maintaining compatibility, versions and updates when referencing external tooling is something that is quite difficult to get fully right.
True, but as long as you bundle it as separate assembly, people can replace it with whatever version of the component they want. With the current approach this is not possible at all since the sources are put inside the SVG assembly.
I see that now, that's really appreciated!
Nevertheless I think you did a great find and shook us awake, so thanks for that! The single DLL is nice, but since the uprising of .NET core your binary folder is likely to be flooded with assemblies anyway. I personally don't really mind multiple assemblies, better yet, the separation of components makes my inner developer very happy. |
|
Wow, very interesting issue. I wasn't aware of that, since I never questioned the license when I forked the library from codeplex... I'll dig into it after work tonight. |
Fortunately Fizzler is mostly a parser building run-time selection via an abstract generator so the code uses very basic types. Version 1.0.0 is actually binary-compatible with .NET Framework 3.5 and Core, provided that you are comfortable with seeing an NU1701 warning. You can test this with the following steps: The output from the last step, the test, was as follows on my machine: So all 220 tests passed using version 1.0 targeting .NET Framework 3.5 while running under a .NET Core 2.0 application! That said, I am happy to add back the .NET Framework 3.5 target if someone is willing to help with adjusting the scripts and CI in a maintainable way; thus a PR would be welcome. You are still free to fork the project but I think the effort would be the same. |
|
Note for @tebjan: the external libraries have not been in the original library, they have been introduced with CSS support in this commit. |
|
I report ExCSS, too.
|
- version 1.1.0. - get from NuGet. - fixes svg-net#563.
Mmm, we can fork the 2.0.3 version and append our changes (from #409) and ship it as a separate nuget or move the ExCSS to a separate project within the SVG solution and put a project reference between the both of them. In both cases we can put a separate license on the ExCSS assembly package or project. |
As far as I confirmed, version 2.0.3 source code did not exist on Github... |
|
In that case, we might consider moving our version to a separate project/repo and publish it as Svg.ExCSS, this will also prevent confusion and accidental package conflicts with existing ExCSS. |
|
I just checked the history, and there have been a number of fixes added (apart from the namespace change) that could be added to the original library. As a first step, I would try to make a PR with these changes (leaving out the namespace change and the formatting stuff), or probably create an issue in ExCss first to check if we could get a new release if we added these changes. Provided that works out, I would revert the namespace change (or probably add an respective alias where needed) and use the library from NuGet same as with Fizzler. If that doesn't work out, I would agree with @gvheertum - create a separate fork/repo with the changes, probably under the vvvv group - @tebjan, would that be possible? |
- fixes licensing issue, see #563
|
Reopen, as the ExCSS part is not resolved yet. |
|
@H1Gdev, @gvheertum : is any of you working on this (e.g.the ExCSS part)? I'm still short on time... |
|
@mrbean-bremen nope, unfortunately not. My time also got cut a bit short due to starting a new job. I hope to be able to do something regarding this ticket next week. Good for pinging for a reminder! |
|
nothing.
If you first create repo, I can do something. |
I wrote it in #563 (comment). |
|
I think we will wait a few days if there is any response to the issue in ExCSS. If not, we have to assume that the project is dead, and we can decide about an own fork. |
|
Ok, the project is obviously dead. There is a more recent fork with .NETStandard support. I think we have these options:
Any thoughts? |
I think this idea is more ideal, but expenses more. |
|
Just to confirm, I do look after ExCss_Core. @TylerBrinks did such good work, it's a shame the original project appears dormant. If you need changes to the ExCss_Core, please fork it, make the updates (including test cases), make sure nothing else is broken, then create a PR. I will update and release to NuGet. |
|
Thanks, @HockeyJustin! |
|
@mrbean-bremen .NET Standard is compatible with all targets, it's a subset of Core and FW. So in theory SVG.NET could be released as Standard only and be compatible with all targets of the project that reference it. |
|
Does that also include 3.5? Because as far as I remember that was a problem in the past. Due to us targeting 3.5 we could not fully go standard, at least something like that pops in my mind.
|
|
Thanks, @tebjan! @gvheertum - I guess we have to try it out... |
|
right, 3.5 wasn't aware of .NET standard. this might help: https://markheath.net/post/supporting-net-standard-and-net-35 |
|
Ok, I checked this out, and it basically says that we need multi-target projects. This is what we currently do in SVG.NET, and if I understand that correctly, we can do the same in ExCSS_Core (provided the code is compatible). ExCSS_Core is currently targeted at netstandard2.0, which is comaptible with .NET >= 4.6.1, so we may add a 3.5 target if possible (which should also cover later .NET versions. |
|
@mrbean-bremen - Agree ExCss_core could not be used for .Net 3.5. Ref: https://weblog.west-wind.com/posts/2019/Feb/19/Using-NET-Standard-with-Full-Framework-NET |
|
From that post:
So I guess it would make sense to target ExCSS_Core to an additional .NET framework. |
|
At the moment SVG nuget package for 3.x version has a reference to Fizzler, so when you add SVG to your project, you automatically add Fizzler, too. 2.x versions don't have this dependency. SVG uses MSPL, but Fizzler uses LGPL. There a lot of reasons, why project cannot use LGPL libraries but can use MSPL libraries (you may ask lawyers, I am no lawyer...). |
|
If you check out the discussion thread you will see that the Fizzler library was already used in 2.x, but it had been copied in without mentioning it or its license. The whole purpose of this issue was to remedy this situation by linking to the library (which is explicitely allowed by the LGPL) instead of just including its sources, which was a violation of the license. Also of course, this kind of usage is not nice to the creator/owner of the library. I'm also not a lawyer, but I know that LGPL libraries are included in a lot of commercial software with no problem if properly attributed, e.g. by mentioning its usage and pointing to its source code somewhere, for example in an about box (I have been involved in license clearing for commercial applications myself). I understand that your legal department may have other opinions, but I don't see an easy way to avoid this at the moment without moving the whole parsing part out of the library and use it only optionally. I think that this would be possible in principle, but somebody has to find the free time to do it of course... |
|
The ExCSS had been handled in #596, so this can be closed again. |
Not a bug report. Was trying to fork this library and spin it for different uses (my own is currently big and will only grow bigger!, needed something smaller to start with) but had issues with the licensing.
@mrbean-bremen @erdomke @atifaziz
The Fizzler library is licensed under LGPL3+GPL3
https://github.com/vvvv/SVG/blob/master/Source/External/Fizzler/Selector.cs
Can the combined sources be licensed under MS-PL?
The original sources on Codeplex and under MS-PL never included the CSS library.
The text was updated successfully, but these errors were encountered: