Loggytronic Forum

VOMP => Vomp For Windows => Topic started by: Chris on June 14, 2006, 00:21:05

Title: Windows Client For VOMP
Post by: Chris on June 14, 2006, 00:21:05
As you may already know, Marten has been working on a Windows port of the vomp client. It is nearly finished but we have hit licencing problems. The binary executable cannot be released under the GNU GPL as everything else is, because part of DirectX (which is a non-GPL component) is statically compiled and linked in to the executable. However, as I understand the legal situation (and please debate this because nobody is 100% clear on this..), the copyright holders for vomp have the legal right to use their code that they have written for vomp in a different closed source proprietary project. Currently I believe this is how vomp for windows could be distributed - it will have a difference non-free licence. If anyone has had similar problems before, or knows or solutions, please do tell.

Anyway, the point is that technically I need the permission of all the copyright holders for vomp to use their code in vomp for windows. Looking at the CREDITS file (which may be missing people, if you have contributed anything and are not in the CREDITS file let me know) - I need the permission of the following people:

Mark Calderbank
Dave Pickles
Brian Walton
André Jagusch
Lars Fredriksson
Pák Gergely
Kimmo Lahdensivu
'jtk'
Marten Richter

Please email me your permission, and optionally post it here as well.

There are still things left to resolve even if all these copyright holders give permission.
Title: Re: Windows Client For VOMP
Post by: muellerph on June 16, 2006, 08:28:24
As most times: IANAL

But anyway, the way it should be done is to keep the GPL V2 and add an exceptional clause stating exactly what you want to do (something like "Binding to DIRECTX on Windows is allowed").
Exchanging GPL V2 with something else would also disturb me, as it involves the possibility to turn the full project into closed source (which is not what is needed AFAICS).
I don't speak native English and I'm not that into the detailed of what needs to be stated technically, but you should add here the term of what you want to add as exceptional clause.
Example for such an exception clause would be e.g. Gstreamer http://gstreamer.freedesktop.org/documentation/licensing.html:

The Muine project hereby grants permission for non-GPL compatible GStreamer plugins to be used and distributed together with GStreamer and Muine. This permission is above and beyond the permissions granted by the GPL licensei by which Muine is covered. If you modify this code, you may extend this exception to your version of the code, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.
Title: Re: Windows Client For VOMP
Post by: MartenR on June 18, 2006, 11:18:29
I think, what muellerph suggest points in the right direction.

First, I want to tell, what are the libraries Vomp for Windows will link to:

1) Import libraries(static link) to various windows system libraries(dynamic link), DirectX system libraries and DirectX Utility libraries and the MS Vc++ Runtime library (dynamic link)

2) A library recommended from the Windows Plattform SDK as basis for DirectShow filters called streambase.lib. streambase.lib provides Base objects for DirectShow filters. It is build from the Windows Plattfrom SDK samples section for DirectShow and static linked to Vomp on Windows.

3) Vomp on Windows will link dynamical to other installed DirectShow filters like the VMR9 and MPEG Video and Audio Decoder filters.


For GPL compatibility:

1) Should not be a problem, since all these parts can be, as I think, regarded as parts as the OS (windows and DirectX) or the Compiler (Runtime Library)

2) Well, for streambase.lib, I'm not sure, if it can be regarded as part of the OS and Compiler etc.. Maybe we have to write for this part a GPL exception.

3) The DirectShow filters vomp links at runtime to, which are part of windows DirectX or DirectShow, like e.g. VMR9 or Filtergraph manager, can be regarded as part of the OS. But in general not the Mpeg Audio and Video Decoder filters, since they are supplied on most (maybe all windows computers?) computers by third party DVD players or similar Applications.
Thus I think we have to write a GPL exception for the Decoder Filters (or all DirectShow Filters) as well.


Well, I have read the FSF FAQ and found some points:
For 3), this point http://www.fsf.org/licensing/licenses/gpl-faq.html#TOCLinkingOverControlledInterface can be a good choice (DirectShow Filter Interface.

For the other things I think, we have to look at this FAQ point also http://www.fsf.org/licensing/licenses/gpl-faq.html#TOCGPLIncompatibleLibs

Marten

Title: Re: Windows Client For VOMP
Post by: Chris on June 21, 2006, 00:06:04
I would love to keep it all under the GPL if at all possible.

So, discussing the GPL FAQ question "What legal issues come up if I use GPL-incompatible libraries with GPL software?"

The special exception provided by the GPL is:

Quote
However, as a special exception, the source code distributed need not
include anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component itself
accompanies the executable.

Made more specific to us:

The source code distributed (what we do already) need not include source code for the binary blobs from Microsoft, unless the binary blobs themselves accompany the executable.

To me, that sounds like if any part of Windows / DirectX is statically linked in (themselves accompany the executable) then this exception cannot be used.

I did read all about adding that exception to the licence to allow others to link with non-free libraries, but thought it didn't apply to us until I found the section in the GPL FAQ that states:

Quote
Strictly speaking, the GPL is a license from the developer for others to use, distribute and change the program. The developer itself is not bound by it, so no matter what the developer does, this is not a "violation" of the GPL.

So, we can give permission for others to link with whatever to create the same binary. We can distribute the binary because we aren't bound by the GPL.

I still don't fully understand how an added exception "wholly outside the GPL" to allow binaries distributed with non-free code can still comply with the GPL - the GPL attempts to give the end user the right to get the source code for all parts of their programs. With vomp for windows we could not do this. Any lawyers here??!
Title: Re: Windows Client For VOMP
Post by: MartenR on June 24, 2006, 07:36:01
@Chris,
what do you think about contacting the FSF (licensing@fsf.org ) and telling them about our problem and what they think would be the best thing for a binary release of the windows client? Maybe they can clarify the situation, since one of their goals is to help developers to write free software.

Quote
Quote
unless that component itself
accompanies the executable.
To me, that sounds like if any part of Windows / DirectX is statically linked in (themselves accompany the executable) then this exception cannot be used.
To this qoute, I'm not sure, if this is so strict, because in every windows program even the windows include files are included and also every compiler add statically linked startup code for the programms. If this is interpreted so strict, I don't think you can build a GPL programm on a non free compiler or OS. I think this is meant for the case, if GPL code is part of the OS, so that e.g. noone can turn linux in to a non free branch. But I'm not a lawyer, so may be I'm wrong.


Marten
Title: Re: Windows Client For VOMP
Post by: Harry on June 24, 2006, 20:22:13
excellent idea.
you could also ask the brilliant Mr. M himself:
http://emoglen.law.columbia.edu/
or, and this may be the better address,
http://www.softwarefreedom.org/

cheers
Harry

P.S GER 2:0 SWE *g*
Title: Re: Windows Client For VOMP
Post by: dbm on June 29, 2006, 09:29:39
Would it be possible/practical to create the desired static binary during the end-user's installation process, using compiled vomp objects and pulling any MS object segments directly from the end-user's own machine?

Even if a link-editor were sent as an EXE with the installer, it could be a custom/one-shot snip/glue engine, good only for melding exactly the right versions of the various parts...

Doing this might appropriately migrate the licensing issue to the end-user/owner of the OS/MS-software, rather than the vomp team.

So long as the GPL code for parts vomp distributes were available to the end-user, the spirit/intent of the GPL might be intact, and the MS distribution issues would be up to the end-users ("i accept", etc.).

I believe the direct-X stuff is freely available from MS - even as a redistributable bundle for vendors to send with their products (ala acrobat reader)


--dbm
Title: Re: Windows Client For VOMP
Post by: muellerph on June 29, 2006, 11:38:55
I think we have two possibilities:
1. Don't do any static linking to non GPL conform libraries at all. Also don't ship/offer any of the non-GPL conform libraries together with the GPL binary.
The GPL is only relevant for the case of distribution, not the development or usage. So if the developer only offers the binary with GPL only (or GPL conform) "data", then the GPL is not violated as everything you offered/distributed is in line with the GPL (and you offer the code/distribute for this part as well). If this then means for the user to link to non GPL conform libraries and the need to get the nonGPL conform libraries from somewhere else, it is the task of the user.
This should not be the preferred cases, i.e. if it involves for the user the need to get the needed libraries from somewhere else in case they are not part of the operating system.
Distributions and so on cannot give one simple package to install. So a lot of users will fail to install/use it.

This case is at least similar to the times when Qt was not free and KDE only distributed/offered their own libraries. The distribution of KDE and nonfree Qt was then done by others. Also the distributors said at the end their distribution is only mere aggregation so most of them included Qt and KDE. But this last point was controversial and therefore not all distributors followed this point (not talking about the ones simply denying every nonfree program). The real problem weren't KDE libraries itself, as they would have had the exception clause, but KDE used GPL only code/libraries from other projects w/o the exception clause granted.

Another similar example is the new way distributors do not include the nonfree graphic drivers anymore. They only provide the pure kernel and leave it to the user to get the non free part. Again, the user have no license issue, the license issue is only for the one who distributes. So the only one who may have an issue are the graphic driver companies, but this detail I leave to the lawyers. Graphic drivers are even more complicated as they share the same address room as the kernel.

While I was coding at KSpread, we had a library included which was not GPL conform (the chart engine). As KSpread and all libraries involved where LGPL only, it was not a big issue, but using this library was for me an issue as their restrictive license would have influenced the whole KSpread. My question to the core devs (David Faure) regarding this issue was simply answered by: As we do dlopen the library it is not in the same address room and therefore not part of the whole. Therefore the restrictive license was only valid for this component itself and this was then a minor issue.

2. Do the exception clause.
If you/all developers (and all statically linked libraries you use and are GPL only) add the exception clause, then it works as well.

Quote
I still don't fully understand how an added exception "wholly outside the GPL" to allow binaries distributed with non-free code can still comply with the GPL - the GPL attempts to give the end user the right to get the source code for all parts of their programs. With vomp for windows we could not do this. Any lawyers here??!

The definition how to license the code lies purely in the right/responsibility of the developer. If the developer wants something differently than the pure GPL, he has the full right to do so. If the user doesn't like these exceptions/changes, then the user still has the full right not to use the program provided. That's when it's called GPL with exception clause.
The GPL in this case reserves your right that any usage of your code must comply with the GPL (beside of the possible exception). For the user you grant the right that if he wants your code then he gets it - if you include an exception then you clearly state that the user doesn't have this right for the mentioned cases. So the GPL is valid for you code, but not for the whole program/binaries involved.

Quote
Quote
Quote
unless that component itself
accompanies the executable.

To me, that sounds like if any part of Windows / DirectX is statically linked in (themselves accompany the executable) then this exception cannot be used.
To this qoute, I'm not sure, if this is so strict, because in every windows program even the windows include files are included and also every compiler add statically linked startup code for the programms. If this is interpreted so strict, I don't think you can build a GPL programm on a non free compiler or OS. I think this is meant for the case, if GPL code is part of the OS, so that e.g. noone can turn linux in to a non free branch. But I'm not a lawyer, so may be I'm wrong.
Partly correct. Includes are in this view copyleft. I know for some cases in the include files there is also code which could be part of the license, but in most cases Includes only defines text with no implemented logic behind. Therefore they are "copyleft". Some companies see this differently but the common understanding of most is that Includes are copyleft.
Linkers/starting code are in this view rather part of the OS and doesn't fit to the GPL clause as well. They must be linked in but are provided by the OS.

But all other statically link libraries must comply to the GPL (or have the exception clause).
Title: Re: Windows Client For VOMP
Post by: MartenR on June 30, 2006, 07:46:32
@muellerph
to 1, this would not be an option for streambase.lib, since streambase.lib has to be linked statically for some technical reasons.
Nevertheless I have thought, if I can replace it with a corresponding part of wine (maybe again a problem since it is published under lesser GPL), unfortunetely, I have yet not found the source code of it in the wine cvs?/svn? (only some mails  about  a winestreambase.lib)- so if someone  can give me a hint, I would appreciate this - so that I can not check, if it provides all neccessary features.

For the directshows filter I think, we can use the way you illustrate in 1, since they are dynamically linked.
For strmbase.lib I think with my todays knowledge, we have to use way 2.

Marten
Title: Re: Windows Client For VOMP
Post by: muellerph on June 30, 2006, 11:10:45
@All:
As I haven't provided any code to Vomp yet, for sure it's not in my intention to give any advise to the original authors how to license their code. If any of the authors of Vomp feels offended by my proposal or wordings, please just say so and I will just shut up. I will accept this without any complain. In such a case please get already my excuse for my words written already.

@MartinR
winestreambase:
I also search for it and also didn't find any real inclusion in cvs. Maybe beside of the offered patch nothing went in. The last mail just included the bz2-patch http://www.winehq.com/hypermail/wine-patches/2005/08/0324.html. Maybe this helps you already in checking if the sources fulfill your needs. Anyway you may contact the author of this patch directly - he should have all detailed infos and may also help in technical details ;).

LGPL of pure Wine will not have any issues at all. LGPL can always be bound to GPL only programs. LGPL has not the "viral aspect" like the GPL, but it has a bit more restrictions to how you provide the source code than the GPL. The last difference is normally not a big issue, as if really something is missing in the distribution we can add it later on without a problem.

@All
If we have to use the way 2 anyway, my recommendation would be to keep the exception clause a bit general. We will not know what maybe needed on top in future versions and if the Windows changes the interface in e.g. Vista again. If we would be to explicit in the exception clause then the needed round for getting all feedbacks to change the clause needs to be done again and again. This would also help avoiding the problems with way 1 for the user and distributors and we could ship one complete binary.

So let's givew some explicit proposals:

Proposal 1:
The Vomp project hereby grants permission for linking against non-GPL libraries on Windows(R) platform to be used and distributed together with Vomp. This permission is above and beyond the permissions granted by the GPL licensei by which Vomp is covered. If you modify this code, you may extend this exception to your version of the code, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.

The last part is also needed, as it gives everybody the possibility to remove this clause again in future versions.
This version would involve mentioning the Windows platform, so it would not be possible to include in later versions a Mac version with similar issues.

This version is very general, it would also give the possibility for others to add a proprietary library in order to display e.g. Newsfeeds or whatever comes to mind as new functionality we would like to see implemented in FOS. So maybe it could be limited to:

Proposal 2:
The Vomp project hereby grants permission for linking against non-GPL video display and streaming libraries on Windows(R) platform to be used and distributed together with Vomp. This permission is above and beyond the permissions granted by the GPL licensei by which Vomp is covered. If you modify this code, you may extend this exception to your version of the code, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.

The most restrictive would be:

Proposal 3:
The Vcomp project hereby grants permission for linking against the non-GPL strmbase.lib library on Windows(R) platform to be used and distributed together with Vomp. This permission is above and beyond the permissions granted by the GPL licensei by which Vomp is covered. If you modify this code, you may extend this exception to your version of the code, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.

As stated in the beginning, I will not give advise to the authors what to do with their code. This I must leave for sure to the authors, i.e. Chris.
Title: Re: Windows Client For VOMP
Post by: MartenR on June 30, 2006, 17:48:22
Winestreambase:
Well, I have checked the diff and I can say, that it does not provide the c++ stream base classes like the windows part does. So it is unfortunetely not an alternative.

Regarding the License proposal, I think something between 2 and 3 would be best, regarding the windows development it would be best to allow  any libraries included or build from the Windows Plattform SDK and Windows and dynamic link to any DirectShow Filter.

Maybe a text like this:

The Vomp project hereby grants permission for linking against any non-GPL  library build or included in  Windows(R) Operating System, its Plattform SDK, DirectX and  its SDK, and any DirectShow filter to be used and distributed together with Vomp. This permission is above and beyond the permissions granted by the GPL licensei by which Vomp is covered. If you modify this code, you may extend this exception to your version of the code, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.


Marten
Title: Re: Windows Client For VOMP
Post by: Schnurps on August 03, 2006, 15:59:32
Hey Marten & Chris,

have you found a solution for these leagal issues?
Sounds like the windows-version is finished except for this...

Yours,
Schnurps
Title: Re: Windows Client For VOMP
Post by: MartenR on August 03, 2006, 17:00:04
Well, we haven't discussed, that issue in the last time. I don't know, if Chris has get feedback from all author regarding the windows client legal issues.
But you are right, except for the legal issue, the windows cleint port is finished since some month ago.

Nevertheless a release would not happen in the next weeks, I won't find time to prepare a fresh executable (holiday).

Marten
Title: Re: Windows Client For VOMP
Post by: Chris on November 05, 2006, 14:36:25
Ok, here goes for more input on the most difficult part of vomp so far... :)

@dbm: I like the idea. I had forgotten you posted it here and came up with it again myself yesterday - it is a nice solution to the problem because nobody is distributing anything that violates the GPL, and what users do with GPL code under their own roofs is as far as I can tell, not our problem. But somebody would have to work out how to actually do it - no small task.

Myself and Mark discussed the release of vomp-for-windows yesterday and came to the following conclusion about distributing and licencing the vomp-for-windows binary under the terms of the GPL: It is impossible.

Why?


So, here are our thoughts on what to do.

--------------------------------------------------------------

The copyright holders of vomp own the code.
The copyright holders of vomp are not bound by the terms of the GPL.
The GPL is the licence used to allow other people to have rights concerning the program.

The vomp-for-windows binary is not distributed under the terms of the GPL because:
- The vomp developers are incapable of granting the following right in the GPL:
  "2. You may modify your copy or copies of the Program or any portion
   of it, thus forming a work based on the Program, and copy and
   distribute such modifications or work under the terms of Section 1
   above, provided that you also meet all of these conditions:"
  ... because the Direct X components are closed source.

The Vomp For Windows Binary _could_ be released _not_ under the GPL because:
- All the copyright holders could decide to do so.
- There is no code in the program licenced to us by others under the GPL. (This has to
  be the case because otherwise: as GPL licencees of other code we would be violating GPL part 2b.)

Re: Exceptions to the GPL
- A user may compile vomp + the Microsoft binary parts themselves for their own personal use.
  There is nothing in the GPL to stop them doing this ??
- A user cannot distribute this binary because the vomp copyright holders licenced the source
  code for vomp under the terms of the GPL which states:
  "You may modify your copy or copies of the Program or any portion
   of it, thus forming a work based on the Program, and copy and
   distribute such modifications ..."
  which they cannot legally do since they cannot modify the Microsoft parts.
- If we add an exception to our GPL licence allowing modified versions of our code to be linked
  with non-GPL software, specifically the Microsoft parts, then the users can distribute binaries.

The exception statement template from the GPL documentation:

"In addition, as a special exception, <name of copyright holder> gives permission to link the code
 of this program with the FOO library (or with modified versions of FOO that use the same license
 as FOO), and distribute linked combinations including the two. You must obey the GNU General
 Public License in all respects for all of the code used other than FOO. If you modify this file,
 you may extend this exception to your version of the file, but you are not obligated to do so.
 If you do not wish to do so, delete this exception statement from your version."

This creates a binary / work that has some parts covered by the GPL and some not.

The vomp developers have to make sure that there is no GPL licenced code in the vomp-for-windows
binary that is not written by the vomp copyright holders. This is because as users of other people's
GPL covered code we are not allowed to re-distribute it in a program linked to non-free libraries.

vomp-for-windows dynamically links to some libraries on Windows. Again, the vomp copyright holders
can distribute a binary that does this. Can users of the vomp code do this?

Extract of the GPL covering what the user must do concerning providing source code to their binaries:
"The source code for a work means the preferred form of the work for
 making modifications to it.  For an executable work, complete source
 code means all the source code for all modules it contains, plus any
 associated interface definition files, plus the scripts used to
 control compilation and installation of the executable.  However, as a
 special exception, the source code distributed need not include
 anything that is normally distributed (in either source or binary
 form) with the major components (compiler, kernel, and so on) of the
 operating system on which the executable runs, unless that component
 itself accompanies the executable."

The GPL states that
- Complete source code must be made available
  - Except parts that are normally distributed (source or binary) as part of the O/S
    - Except if the part in question is actually in the original distributed executable

The libraries that vomp-for-windows links to are distributed as part of the O/S
_and_ they are not part of the vomp for windows executable. Therefore licencees of vomp
need not provide the source code to these dynamically linked libraries.

Conclusions:
1. vomp-for-windows binary is releasable, but is not a binary covered by the GPL.
2. Must remove any source code in vomp that is licenced to us under the GPL.
3. Must add GPL exception to the licence so that our licencees can create & distribute the same/modified binary that we can.
4. Must get permission from all vomp copyright holders to link and distrbite their code against non-GPL code.

-----------------------------------------------------

So, input please. Personally I think this is the answer as I cannot see how we would be violating the GPL if we did this. (Actually I havn't read the Microsoft distribution licence recently but I don't think it will be a problem).
Title: Re: Windows Client For VOMP
Post by: davep on November 05, 2006, 20:51:31
"The copyright holders of vomp own the code."

Do they? The largest item that I've contributed to date is the I18n code, and that was copied more-or-less directly from VDR. I believe other projects have 'assisted' in the same way. All perfectly permissible under the GPL of course.

Dave
Title: Re: Windows Client For VOMP
Post by: Chris on November 05, 2006, 23:23:22
Damn, I had forgotten about the I18n module. Hmmm.
Title: Re: Windows Client For VOMP
Post by: MartenR on November 06, 2006, 07:53:27
But, I think we can easily replace the i18n module. It would not be so hard to do this. The question is have we to change the interface or just to reimplement the class?

Other parts I'm suspicious about not being developed by the vomp team:
* Fonts (but they seems not to be GPLed but under a more liberal license, so we could use them?)
* Pictures - VDR logo and the wallpaper seems to be not from the vomp team, but I'm unsure if they are GPL'ed
* Jpeg lib (but this is not included in the windows version, windows function are used instead)
* stb.h (but also not used at the windows version)(other stuff from mvpmc, that went into vomp, (demuxer?))

Marten
Title: Re: Windows Client For VOMP
Post by: Chris on November 06, 2006, 13:50:40
I have a similar list here. I also have some ideas for how to re-implement I18n amongst other things. Even if the JPEG lib were to be used it isn't a problem, it's a very liberal licence. Where is the licence for the fonts? The demuxer is completely re-written by Mark, so that is ok. There should be very little of mvpmc code left but stb.h might need some looking at. Well, it definitely needs some looking at - it's messy the way it is used at the moment. I did ask Jon Gettler once about the information gained from the mvpmc project and his view on it was that structure and ioctl information (rather than using chunks of code) were not a problem to copy and use.
Title: Re: Windows Client For VOMP
Post by: MartenR on November 06, 2006, 18:27:33
Where is the licence for the fonts?
It is in the cvs /client/fonts/license.txt . There are several licenses in it, but it is not clear to which helvetica belongs, but most of them are also very liberal. And for the pictures /client/other/license.txt.
but stb.h might need some looking at.
Not really, the windows code don't include it. I have run a windows build and placed a #error inside "stb.h" and the compiler did not complain, thus it is not necessary to be non GPL for the windows version.

Marten
Title: Re: Windows Client For VOMP
Post by: MartenR on November 20, 2006, 07:40:57
I have managed to remove the streambase.lib, the only static bind library that remians is strmiids.lib, but there are only guids of the objects included, thus it is something like a com import library. All other MS libs are only dynamical linked.
 I suggest we have not a GPL problems. Am I right?

Marten