[Bobbu]

I've had the JD source code to develop my own personal plugins and modifications for quite a while now. Recently however with the recent ZippyShare issues and my usage of the service I decided I would fix it for myself only to discover the source code for its hoster plugin isn't on the public SVN, and its compiled DataDump.class is encrypted to hinder decompilation.

I am wondering why is this so? How is one meant to get access to its source code? How does this all not conflict with the GPLv3 license, which requires "equivalent access" to the source code as the object code, that JD uses which should also include the plugins?

[raztoki]

Source was removed due to cat and mouse games by the provider. This is rarely used for plugins, but in this case it has been not available for maybe 6-7 years.


raztoki

[Bobbu]

That reasoning is along what I was thinking of. I do question the effectiveness of this though as it really isn't difficult for an experienced developer to reverse the code using a decompiler despite the encryption used, nor is it real difficult for providers to make significant enough changes that break plugins without even requiring analysis of the plugin code.

But I digress my other question remains how does it being unavailable not conflict with the GPLv3 license? Under GPLv3 the distribution of the compiled object code also requires the covered source code to also be made available with "equivalent access", and the plugins by nature of their design would be covered under GPLv3 as they are compiled inheriting directly from code within the covered main application and are essentially treated as dynamically linked libraries by it at runtime.

Looking through the license included with JDownloader I find no exceptions that would allow withholding or restricting access to plugin source code, so to me it seems this would be in violation of the GPLv3. Even if it's available within a user restricted repository where access is granted on a request basis, which I've seen no evidence of being the case, I still don't feel that meets the requirements of "equivalent access" set forth in the license as the object code is freely distributed without any such restrictions so it can still be argued to be a violation of the license.

[coalado]

I agree with most of your arguments and that GPLv3 might not have been the best choice for a license.
However, it is unfortunately hardly possible to keep these parts open source. This would result in a lot of additional work. These plugins have been open before.

However, in my understanding, it seems possible to have closed-source plugins within GPL software as long as they are not essential for the software itself.

Do I understand correctly that you suggest changing the JDownloader license to something less "open" and more flexible? This would - of course - be an option. Do you have any special solution/license in mind?


BTW: We already wrote you an email offering the source code two days ago - so you should indeed have evidence of getting code access on a request basis. Did you receive this mail?

[Bobbu]

Originally Posted by coalado

BTW: We already wrote you an email offering the source code two days ago - so you should indeed have evidence of getting code access on a request basis. Did you receive this mail?

Sorry didn't see this edit until now. I rarely use the email I signed up this account with but have just checked and have indeed received the email. I honestly don't really need the code for the plugin now, I admittedly managed to decompile it, but it might be handy in the future so I may shoot an email back about it later.

I may question how effective of a defense it may be but I definitely understand the desire or need to keep the source for some parts of the software closed or otherwise restricted. You're right the GPL can be interpreted differently on this point and I'm definitely no expert on it, we've both said our piece so I won't keep beating a dead horse about it.

Ultimately whether it strictly adheres to the license or not really isn't that important to me compared to whether the closed source is still somehow available to those that really want access, and since that is the case I'm fine with it.

As for helping contribute and maintain to the plugins I'm afraid I'd have to say no, maybe in the future I may feel I could contribute something but right now I honestly don't have the patience or dedication for something like that.

[Bobbu]

I'm not suggesting the license be changed, I'm suggesting that the (un)availability of the source code not to violate the license its object code is distributed under. Also even if the license is changed in the future it wouldn't retroactively apply to older distributed copies and thus the source code for those older copies must still follow their old license.

To my understanding of the GPL closed-source plugins are only allowed if the main program and the plugin do not constitute a single piece of software, this basically means they don't share intimate communication with complex data structures. In the case of JD it would most definitely constitute a single piece of software as the plugins inherit directly from code defined within the main program sharing intimate communication and data structures. Essentiality isn't an important criteria compared to the interaction between the main program and plugin, but even if it was in JD's case I would argue the plugins are an essential part of the software as they perform functionality critical to fulfilling the software's purpose in supporting the automation of downloads from various services.

[coalado]

I agree that the GPL can be interpreted differently concerning this point. Plugins have a limited API to the JDownloader core, and I do not have a proper definition for "complex data structures". Just the fact, that Plugins extends abstract JDownloader classes, does not create string coupling. The plugin cannot be built without JDownloader, but JDownloader can be built and run easily without Plugins. THAT's essential for us.


Anyway, the majority of JDownloader is open source. There are plugins for several thousand websites. I do NOT agree that Zippyshare is an essential part of the application.

However there are a few closed-source parts, and we cannot treat them like the open-source parts. If we are forced to get active in this matter, the only way we can go is a way even further away from open source. (I know that this would not apply to old code, but for all coming updates.


How about you start contributing and maintaining the closed plugins and keep them working? We would be happy to release the code if someone helps.