Author Topic: GPL issues with ML post processing software  (Read 74002 times)

g3gg0

  • Developer
  • Hero Member
  • *****
  • Posts: 3154
Re: GPL issues with ML post processing software
« Reply #75 on: August 28, 2014, 08:28:55 PM »
Already done.
cool, where can one download the GPL'ed sources of RareVision that contains GPL code?
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: paypal@g3gg0.de
ONLY donate for things we have done, not for things you expect!

peoplemerge

  • Freshman
  • **
  • Posts: 50
Re: GPL issues with ML post processing software
« Reply #76 on: August 30, 2014, 05:27:49 PM »
Instead of copying the source or object code into an app (like Thomas Worth's), would there be any problem in creating a shared library containing those implementations?  Most of the post processing I do is in bash, but I might like to be able to use a different high-level language like python, ruby, or java (all of which can depend on shared libraries) to achieve a level of efficiency in automation that is tailored to me that I can't get with a gui or bash.  Hell, maybe other vendors like Adobe would produce support as well, if this were more developer friendly.  Yeah, I know, dream on ;]

One of the benefits of GPL is that it protects the customer.  Suppose I became dependent on Thomas's tool, but then the GPL code were to fix a bug that I found desirable (or even if MLV format changed), all I would need to do is build a new shared library, swap out the one that RawMagic uses with that one, and as long as the code syntax and semantics hadn't changed, I'd be good to go.

The reason that's good for the customer is that if Thomas were to copy compiled artifacts into his app, I would have no recourse if Thomas got too busy to produce an update, decided to cut support, or became otherwise unavailable.  If he just depended on a library, I as a customer would be protected.

I'm not a lawyer, but isn't this shared library approach permissible in GPLv2?

If this seems like a worthwhile direction to you, I'd be happy to investigate what would be needed to produce that shared library.  I'll have some time later next week because I'm taking a week off between day jobs :)

Happy shooting, folks!

Thomas Worth

  • Member
  • ***
  • Posts: 194
Re: GPL issues with ML post processing software
« Reply #77 on: August 31, 2014, 10:44:03 AM »
Instead of copying the source or object code into an app (like Thomas Worth's)
RAWMagic does not contain any GPL code. This is a misconception.

Quote
One of the benefits of GPL is that it protects the customer.  Suppose I became dependent on Thomas's tool, but then the GPL code were to fix a bug that I found desirable (or even if MLV format changed), all I would need to do is build a new shared library, swap out the one that RawMagic uses with that one, and as long as the code syntax and semantics hadn't changed, I'd be good to go.
You can indeed do that now.

Quote
I'm not a lawyer, but isn't this shared library approach permissible in GPLv2?
From what I understand, no. The code is still executed within the main binary, so this doesn't meet the requirements. A separate binary could be implemented, itself compiled from GPL code, which is what I've done with RAWMagic. This separate binary must itself be open source, of course.

LGPL would allow the shared library approach, which would give better performance and streamline development of commercial apps. I proposed the LGPL idea to the Magic Lantern developers, but they aren't interested.

g3gg0

  • Developer
  • Hero Member
  • *****
  • Posts: 3154
Re: GPL issues with ML post processing software
« Reply #78 on: August 31, 2014, 12:33:58 PM »
iirc even shared libraries are not enough.
it should be a separete binary that you can call via command line.
just making a lib from GPL code and link that dynamically is similar to putting GPL code into a .c and linking that .o

so .so/.dll are too close to the clearly forbidden things when using GPL.

-> overall recommendation: build an interface that doesnt rely on loading the GPL image into the same process RAM, like calling it from shell
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: paypal@g3gg0.de
ONLY donate for things we have done, not for things you expect!

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 12360
  • Quarantined
Re: GPL issues with ML post processing software
« Reply #79 on: September 04, 2014, 02:27:32 PM »
RAWMagic does not contain any GPL code. This is a misconception.

It relies on my GPL code to do its basic functionality. You may have found an workaround that bypasses the GPL (like using two separate binaries), but you are still profiting from my code without permission.

And your workaround is questionable btw:
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation
http://lwn.net/Articles/417852/

Thomas Worth

  • Member
  • ***
  • Posts: 194
Re: GPL issues with ML post processing software
« Reply #80 on: September 04, 2014, 08:15:03 PM »
It relies on my GPL code to do its basic functionality.
If one converts RAW or MLV files with RAWMagic that don't suffer from the vertical stripes issue, no GPL code is employed whatsoever (external binary or otherwise) since vertical stripes correction isn't needed. So no, basic functionaity does not rely on GPL code. I assume that's the code you are referring to.

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 12360
  • Quarantined
Re: GPL issues with ML post processing software
« Reply #81 on: September 04, 2014, 09:20:02 PM »
If it were true, you would have little or no reason to rely on the GPL code, right?

Thomas Worth

  • Member
  • ***
  • Posts: 194
Re: GPL issues with ML post processing software
« Reply #82 on: September 04, 2014, 11:48:01 PM »
Only for vertical stripes correction, and only to stay consistent with other ML tools. So, only four GPL functions which are related to stripes correction.

I'm not sure what you're implying. Are you saying you think RAWMagic's core conversion engine is based on your code, e.g. raw2dng?

chmee

  • Contributor
  • Hero Member
  • *****
  • Posts: 1031
  • raw2cdng
Re: GPL issues with ML post processing software
« Reply #83 on: September 05, 2014, 12:21:26 AM »
the question is not "how many/often", but "if".

g3gg0

  • Developer
  • Hero Member
  • *****
  • Posts: 3154
Re: GPL issues with ML post processing software
« Reply #84 on: September 05, 2014, 01:18:28 AM »
point is
a) you used GPL code in some of your versions
b) you sold them without releasing GPL'ed source

until today we didnt see *these* versions that contain one or more lines of GPL code released under GPL.

it does NOT matter that today there is just a few lines of GPL code, or even no GPL code anymore.
the OLD versions still are not GPLed! and this means: you are still ignoring GPL.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: paypal@g3gg0.de
ONLY donate for things we have done, not for things you expect!

a1ex

  • Administrator
  • Hero Member
  • *****
  • Posts: 12360
  • Quarantined
Re: GPL issues with ML post processing software
« Reply #85 on: September 06, 2014, 09:11:42 AM »
Looks like a GUI wrapper over a command-line GPL program must also be GPL:
http://stackoverflow.com/questions/392395/a-gui-wrapper-around-a-gpl-cli-application-is-it-a-derivative
http://programmers.stackexchange.com/questions/110380/call-gpl-software-from-non-gpl-software

Quote
IMHO, in spirit, a pure wrapper that merely exposes the functionality of a GPL program should be GPL.

Therefore, I suggest enforcing GPL compliance on all the postprocessing apps based on ML command-line tools.

Authors who do not respect the license will have their threads locked. If no corrective action is done within 1 month, their threads will be deleted.

Any objections?

Thomas Worth

  • Member
  • ***
  • Posts: 194
Re: GPL issues with ML post processing software
« Reply #86 on: September 06, 2014, 12:34:53 PM »
Therefore, I suggest enforcing GPL compliance on all the postprocessing apps based on ML command-line tools.
As stated previously, RAWMagic is not based on any ML command line tools, nor does it require any GPL code (either linked to the application or calling a separate binary) from the Magic Lantern project to operate. Its core functionality comes from 100% proprietary code, just to be clear. It is not a "derivative work." Far from it.

RAWMagic is certainly not a wrapper over a GPL program, although some, if not most, of the other post-processing apps on this forum are.

chmee

  • Contributor
  • Hero Member
  • *****
  • Posts: 1031
  • raw2cdng
Re: GPL issues with ML post processing software
« Reply #87 on: September 06, 2014, 12:59:10 PM »
@Thomas Worth
loool. i'm really tired of your beating around the bush...
you? gpl? no? yes?

ayshih

  • Contributor
  • Senior
  • *****
  • Posts: 266
Re: GPL issues with ML post processing software
« Reply #88 on: September 06, 2014, 09:09:27 PM »
I've had to wade through licenses on other projects, and the "viral" nature of GPL always leads to furious debate.  Here are my comments:

Looks like a GUI wrapper over a command-line GPL program must also be GPL:
Both fortunately and unfortunately, that's not automatically the case, and the links you cite also show that.  It depends on many factors, including how the wrapper and the GPL program communicate.  FSF's GPL FAQ on this issue acknowledges that the murkiness has to be resolved on a case-by-case basis based on the mechanism and semantics of communication.  There is a space for non-GPL programs to call GPL binaries and still be compliant with GPL.

Even if wrappers automatically had to be GPL-ed, I have to agree with Thomas Worth that it seems inaccurate to characterize RAWMagic as a wrapper.  I don't know what the distribution of RAWMagic users, but it seems like there could reasonably be a significant fraction of the user base has no need for the vertical-stripes correction.

point is
a) you used GPL code in some of your versions
b) you sold them without releasing GPL'ed source
...
the OLD versions still are not GPLed! and this means: you are still ignoring GPL.
This is a clear violation of GPL, and something that Thomas Worth must address and remedy.  Unlike the above debate, direct integration of GPL code triggers GPL protections.  You can't get around this.

Therefore, I suggest enforcing GPL compliance on all the postprocessing apps based on ML command-line tools.

Authors who do not respect the license will have their threads locked. If no corrective action is done within 1 month, their threads will be deleted.
Again, it's possible for non-GPL postprocessing apps to use ML tools while still being compliant with GPL, depending on the nature of the communication.  However, reasonable people can disagree about where that line gets drawn.  So, instead of dealing with the recurring debates over GPL compliance, simply only allow threads on this forum for GPL apps.  Thus, unless Thomas Worth distributes RAWMagic under GPL, its forum thread will be locked/deleted regardless of the app's compliance with GPL.
Canon EOS 50D | 17–40mm f/4L & 70–300mm f/4.5–5.6 DO IS | Lexar 1066x

Audionut

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3584
  • Blunt and to the point
Re: GPL issues with ML post processing software
« Reply #89 on: September 06, 2014, 11:26:48 PM »
I don't know what the distribution of RAWMagic users, but it seems like there could reasonably be a significant fraction of the user base has no need for the vertical-stripes correction.

I don't understand the point you are trying to make here.  On what basis does the size of the userbase affect GPL?

ayshih

  • Contributor
  • Senior
  • *****
  • Posts: 266
Re: GPL issues with ML post processing software
« Reply #90 on: September 06, 2014, 11:45:59 PM »
It's about whether RAWMagic can be labeled a "wrapper" and whether the ML tool can be considered part of the core functionality of RAWMagic.  For example, if vertical-stripe correction is used by the majority of the RAWMagic user base, that can be contributing evidence that the ML tool is effectively core functionality, even if it is not necessarily implemented that way.

All parties here are unlikely to ever agree on whether or not RAWMagic is, in its current form, is compliant with GPL, and I suspect that Thomas Worth has a defensible position (not counting the clear GPL violation of earlier versions).  If the stakes were higher, this would be adjudicated in a legal system, and even then the parties would likely not agree on the outcome.

Again, I like the approach of simply declaring that this forum will only allow threads for GPL apps.
Canon EOS 50D | 17–40mm f/4L & 70–300mm f/4.5–5.6 DO IS | Lexar 1066x

Audionut

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3584
  • Blunt and to the point
Re: GPL issues with ML post processing software
« Reply #91 on: September 07, 2014, 12:14:39 AM »
I think closing and deleting threads is a last resort (and we're probably already there), but I think the main intent is/was to support these other applications on the basis that the core project (ML), would gain development progress through this support.

If I know the developers well enough, simple compliance with GPL by these other applications would have been fine also.

In my mind, there is no agreement or disagreement.  These other applications exist solely thanks to the development of ML.  So regardless of all other issues, there should be some reasonable expectation to respect the wishes of that development team.

As far as I'm concerned, Thomas Worth has ignored all reasonable requests by the development team, and now expects the development team to assume his application abides by the GPL, based solely on his word.  Support for his applications should be immediately ceased from these forums. 

However, I'm not sure if blanket banning all non GPL applications is the right approach, based on my first paragraph.

Thomas Worth

  • Member
  • ***
  • Posts: 194
Re: GPL issues with ML post processing software
« Reply #92 on: September 07, 2014, 04:40:07 AM »
As far as I'm concerned, Thomas Worth has ignored all reasonable requests by the development team, and now expects the development team to assume his application abides by the GPL, based solely on his word.  Support for his applications should be immediately ceased from these forums.
I have not ignored any requests. In fact, I went to great lengths to try to appease the ML team. Anyone who reads this forum can figure that out.

It seems there's nothing I can do to make you guys happy. So, if you think it's good for the community to delete the RAWMagic thread, I guess I can't stop you.

How do you think your users would feel about that? Perhaps you should take a poll before making a decision.

dmilligan

  • Developer
  • Hero Member
  • *****
  • Posts: 3218
  • 60Da / 1100D / EOSM
Re: GPL issues with ML post processing software
« Reply #93 on: September 07, 2014, 06:07:47 AM »
Since RAWMagic is available through the Apple App store, that means Apple has reviewed the code. It may be possible to file a DMCA takedown notice with Apple since this would be a violation of copyright (if in fact Thomas has infringed the GPL, personally, I will take him at his word that he hasn't). Apple could verify whether or not RAWMagic is in violation of the GPL.

Audionut

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3584
  • Blunt and to the point
Re: GPL issues with ML post processing software
« Reply #94 on: September 07, 2014, 11:28:48 AM »
Thomas, if you call months of no communication, and then telling everyone to "think of the users", as respecting the developers of this project, then I stand corrected!

g3gg0

  • Developer
  • Hero Member
  • *****
  • Posts: 3154
Re: GPL issues with ML post processing software
« Reply #95 on: September 07, 2014, 12:58:59 PM »
i didnt see any move forward. GPL violation is still present.

point is
a) you used GPL code in some of your versions
b) you sold them without releasing GPL'ed source

until today we didnt see *these* versions [...] released under GPL.

solution: release source
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: paypal@g3gg0.de
ONLY donate for things we have done, not for things you expect!

spnsir

  • New to the forum
  • *
  • Posts: 48
Re: GPL issues with ML post processing software
« Reply #96 on: September 10, 2014, 08:02:21 AM »
I'm extremely appreciative of ML and RawMagic. Both have enabled me to take my work to the next level, ML of course with RAW/MLV video, and RawMagic being integral in conversion into a Davinci Resolve audio-synced dng sequence. I hope you can all find a solution and move forward with no bad blood.

peoplemerge

  • Freshman
  • **
  • Posts: 50
Re: GPL issues with ML post processing software
« Reply #97 on: September 10, 2014, 07:38:19 PM »
There is another way around the previous versions with GPL code.

If you did not buy a RawMagic version with GPL code, you have no standing to demand the source code for RawMagic.

If you did buy RawMagic with GPL code and you still possess it, you can demand the source code.  At that point, Thomas can refund your money and claim you are not a customer.  Then you have no standing again.

I propose a new implementation of the post-processing code with an Apache license.  That would encourage other firms wanting to make life easier for ML users building support for MLRaw.  LGPL is an alternative (looks like FFMPEG uses that https://www.ffmpeg.org/legal.html).  There are probably some pitfalls but there is probably a way where everyone wins if it's done considerately.  Worst case, it would mean rewriting it all, which is a nontrivial effort

Opinions?

g3gg0

  • Developer
  • Hero Member
  • *****
  • Posts: 3154
Re: GPL issues with ML post processing software
« Reply #98 on: September 10, 2014, 10:33:09 PM »
There is another way around the previous versions with GPL code.

If you did not buy a RawMagic version with GPL code, you have no standing to demand the source code for RawMagic.

If you did buy RawMagic with GPL code and you still possess it, you can demand the source code.  At that point, Thomas can refund your money and claim you are not a customer.  Then you have no standing again.

wrong. GPL requires the seller of a program to either distribute the whole source code with the GPLed binary, or
to provide a clear instruction how to get the source code.
not doing that is alreay a violation of copyleft rules.

we are not trying to find a way around this situation.

we say:
 - we give thousands of hours of work on unique tools away for free
 - if you re-use parts of our work, do so - we are happy about that
 - the only restriction: do it for free, just like we did!

thats why we use GPL.
if one cant live with that, he must not re-use our work, no matter how much of it.
Help us with datasheets - Help us with register dumps
magic lantern: 1Magic9991E1eWbGvrsx186GovYCXFbppY, server expenses: paypal@g3gg0.de
ONLY donate for things we have done, not for things you expect!

peoplemerge

  • Freshman
  • **
  • Posts: 50
Re: GPL issues with ML post processing software
« Reply #99 on: September 12, 2014, 03:22:09 AM »
Let's separate the free software discussion from the open-source discussion.  Yes, not having to pay for software is great.  Open source software is great too.  They're distinct ideas, though.

I went to a talk by Richard Stallman some years ago where he told an anecdote of a firm he went after for copyleft infringement.  He bought their software which depended on a GPL library.  He wrote them demanding the source code.  He heard nothing for six months.  Six months later, they returned his check with a note from their lawyer saying he was not a customer.

The talk he gave was at a meeting held by a local university, where he promoted the idea that GPL supports those of us who want to make a living as developers.  A common scenario is that you work for a firm building software and they are your customer.  You have only one customer, and you're going to give them your code.  If you want a customer #2, then good luck getting them to pay you since it's open at that point.  Anyway, that's a typical scenario.

The alternative for the firm in question was to release the source code.  They decided they would rather not have Stallman as a paying customer.  Real users weren't willing to put pressure on their vendor to release the source code because they liked the product.  The story basically ended there.

I see a lot of similarities in this case.  If at some point in time there was a version that had GPL, and when someone complained, Thomas Worth in good faith remedied the situation by removing GPL code, that should be satisfactory.  To say it's not good enough sends a message to the world at large not to adopt MLV.  It just seems like an extreme position to me.

My main concern here has nothing to do with the particulars of RawMagic, it puts into question the viability of developing any meaningful post-production workflow for the larger community.  If Thomas Worth faces this amount of hostility, then we'll definitely never see MLV support in any of the nice post-production tools we all know and love.

Also, just because there once existed a copy of software called RawMagic in the universe that had GPL code, that anyone anywhere can demand to have it open is a pretty scary thought.  In his case, it really doesn't seem like he intentionally set out to violate the license and abuse the thousands of hours of work you've contributed.

g3gg0, I really hope you reconsider your position.  The Linux kernel, fair enough, GPL.  Basically every library that programmers use enables programmers to charge for their time.  I like the idea of ML code that runs in-camera to be GPL for the same reason I like Linux to be GPL.  But the post workflow that's supposed to provide convenience for users should adopt a more flexible, programmer-friendly model.

What are the options for well-intentioned programmers who want to work for food?  Let's say I wanted to work for a studio that just decided to use MLRAW on a crash cam for a small part of their production.  If I were to tell them that I had to release any code I wrote for their in-house video management system as open source -- or in the extreme case, their whole platform, I would be out of a job for sure.