5 ms·

Here is the problem though: let's assume that the developer really wants to release the source code, but the problem is that they have used a third-party librar

Here is the problem though: let's assume that the developer really wants to release the source code, but the problem is that they have used a third-party library where they cannot legally release because they simply don't have the rights to it. This complicates open-sourcing that software (this is already proven from time-to-time, for example the OpenJDK Java runtime needs to and has changed third-party components like the colour management system, font renderer and media framework). This can be worked around on actively-developed software or if the community wants to be involved on open-sourcing that software, but if it is being abandoned I don't see the incentive to replace these components. Moreover, comments. From expletives to actual trade secrets, a company needs to audit the code to ensure that at least the trade secrets have been removed from the source code. For example, even though Microsoft does not release the Windows/NT code widely, there are checks to ensure that expletives and comments that might cause severe repercussions (i.e. political statements) are not inserted. However, this is definitely a lesser concern to individual or small-group developers. (Plus tooling issues etc, but considering that the massively-popular and ported Doom exists, it might be solved by the community. However, software which no longer has a community will encounter these issues.)

fsflover 6y ago
> but the problem is that they have used a third-party library where they cannot legally release because they simply don't have the rights to it. Just release everything else. Someone can write their own library for that or maybe even find a replacement in the open-source world.
- ghaff 6y ago
  Unless it's something wildly popular, to a first approximation, no one is going to go to the effort to get a discontinued game or other software into a usable state given missing libraries, build systems, developer docs, etc. And, as parent noted, it's still quite a bit of work to open source proprietary code even if a company has a genuine interest in doing so. I have first-hand knowledge of situations where a company wanted/needed to open source acquired code and it took a good year of concerted effort to do so.
  - colonwqbang 6y ago
    In the second paragraph of the article the author describes how some dependencies of the application were replaced by open-source libraries like SDL. There are also many more examples of this happening. So the assertion that "nobody" would do it is wrong. If the application is interesting, people will find find a way to run it on modern hardware. It's not an excuse not to open-source what you can of your code. This line of excuses is just weak. Either release the code or keep it proprietary, that's your decision as owner. Just spare us the silly excuses and trying to make it seem like your company would really really like to open-source if only it wasn't for that tiny detail of blah...
    - johannes1234321 6y ago
      Getting rid of third party's code often isn't as easy as removing a folder and be done. Sometimes third party code is deeply integrated and was patched and can't be isolated or it might be the core component/core engine where the missing make aThe reminder almost useless. Also some vendors put their APIs behind an NDA, thus you not only have to remove the API, but also rework the calling code. (Just for open sourcing fighting whether the NDA is legally clair is quite some effort ...) This also becomes fun if you worked with external contractors, who committed all over the code and the agreement doesn't cover releasing the code. And then there are still all the other things in open sourcing (making sure comments are appropriate, naming is appropriate, ...) And then you have IP besides the source, in artwork where designers often have some rights, copyrights, trademarks ... And after all that the "fear" on your reputation, if one fears the code might seem of low quality, which might reflect bad. (Whether it's truly bad doesn't really matter, a few blog posts or youtube videos of somebody taking worst parts can harm reputation) It's all simpler, if you plan on doing that eventually from the start, but notable effort for any serious project after the fact.
      - colonwqbang 6y ago
        It seems unwise to let control of your product degrade to the point where you cannot draw a line between code you own yourself and encumbered/external code. It should be possible to avoid with proper planning. Still, you're probably right that it is a common situation. Your other examples mostly seem to boil down to "we were not willing to commit the necessary resources to do it". Which is fine, of course.
- maccard 6y ago
  If you don't have the rights to release it you likely don't have the rights to redistribute the api either, so you need to strip that out.
  - deleted 6y ago
    [deleted]
  - syshum 6y ago
    Well I hope then that Google wins against Oracle and we can finally say API's are not copyrightable...
    - deleted 6y ago
      [deleted]
    - maccard 6y ago
      Even if that is the case, there's a difference between an api being copyright protected, and an api being redistributable
      - syshum 6y ago
        In what way exactly? Copyright law is the only method a person has to control how it redistributed, if there is no copyright on the API then no one has the legal authority to prevent redistribution.
        maccard 6y ago
        Contract law. I'm not aware of it having been tested, but a contractual obligation not to distribute something is not the same as something not being copyrighted. See the post on HN yesterday about atlassian not allowing performance comparisons as part of their TOS.
        zinekeller 6y ago
        Note: US law, obviously (these points are moot in EU due to strong laws for interoperability). Contracts can legally bind the developer/s with this, more so if it is a corporate entity. Even if Google wins this case and the APIs cannot legally acquire copyright protection, the third-party can sue the developer/s for disclosing trade secrets. The code legally is clean (IP-wise) at this point, but the developer/s have broken a contract with the third-party provider in doing so, and they can sue those developer/s (however, any users of the released code are protected since they are not the signatories/parties to the contract).
- Thaxll 6y ago
  As if it was just that easy to remove all part of third party code ... For example removing a physic engine from a game is pretty much "impossible".
  - Ace17 6y ago
    It depends on how the physics engine has been integrated into your game/engine. The book "Game Coding Complete" shows how to isolate a 3rd-party physics engine so you can switch implementations. Of course, every physics engine behaves a little differently from the others, so, if you game is physics centered (pinball, racing), switching implementation might result in a slightly different game - but having the core of your game depends on the implementation details of some 3rd-party library might not be a good idea anyway. In general, the more you sprinkle your code with dependencies to 3rd party libraries, the less control you have over the resulting product. Your point still stands, though, for some very low-level "utility" libraries like boost or the STL, or any standard library replacement , and more generally, libraries holding "vocabulary" types.
  - deleted 6y ago
    [deleted]
- jandrewrogers 6y ago
  There are a surprising number of cases where it is extremely unlikely that a library is replaceable even if the use case is popular and there is no restriction on making an open source replacement. The overhead cost of open sourcing software can be high, which must be offset by a realistic expectation that value will be created by open sourcing it. There are two common cases not considered here of which I've seen several examples of libraries in my world. First, replacing the library requires extremely high/rare expertise and several man-years of development to implement a basic version. These never get replaced in open source because the level of individual investment is extraordinary; these libraries only get built when a company invests a few million dollars hiring one of the handful of people that know how to write one over years, which is rare and at which point they want to own it. The barrier to open source MVP is simply too high. Even worse, in some cases the licensed version becomes unavailable/unsupported because the person that designed it moves on but at least there is an incentive to spend a lot of money to remedy that. Second, replacing the library requires computer science that has no description in literature. I've seen teams of CS PhDs spend years trying to clean room equivalent libraries with little success when there are few hints in existing computer science literature how the original library capability was even achieved. They might be able to buy a license to the original library but many times that is cost prohibitive (millions of dollars) or not available at all (licensing restrictions). Not every application has a library dependency with these properties but it isn't that rare either. These libraries are used for good reason and sometimes provide central functionality without which the rest of the source code is relatively low value.
  - matheusmoreira 6y ago
    > the library requires extremely high/rare expertise and several man-years of development to implement > the library requires computer science that has no description in literature Can you mention examples of such cases?
MayeulC 6y ago
> but the problem is that they have used a third-party library where they cannot legally release https://github.com/id-Software/DOOM https://github.com/id-Software/DOOM The DOOM source code was released without sound support due to this: > The bad news: this code only compiles and runs on linux. We couldn't release the dos code because of a copyrighted sound library we used (wow, was that a mistake -- I write my own sound code now), and I honestly don't even know what happened to the port that microsoft did to windows. This isn't always a true dichotomy. Any code is better than none, you don't have to release all of it to make a difference (especially if the closed-source library is provided as a shared object). The code could be provided in a non-functionning state, it would already be a lot more helpful than binary patching while relying on disassemblers. A closed-source library can be worked around (stripping functionality), replaced, re-implemented, linked against a blob, reverse-engineered, etc.
- zinekeller 6y ago
  I actually used Doom as an example of software that has received a great (it might be even the greatest) community help. However, this comment (https://news.ycombinator.com/item?id=25622021 https://news.ycombinator.com/item?id=25622021) has succintly described further the issues of open-sourcing a previously closed-sourced software. One of the most important point here is the fact that some software code are not organized could have a surprise third-party code which required intensive audits. Obivously, in some cases it is simply not economical to do such auditing.
blablabla123 6y ago
That might be quite a blocker for closed-source commercial apps that are distributed to the user. On the other hand in-house apps and web apps usually don't suffer this problem from what I've seen. Most of the time open source libraries are strongly preferred and even if not, the closed sourced licenses for dependencies can easily be obtained by the intended user oftentimes. (At least frontend dependencies need to be MIT or BSD licensed anyway)
- tjalfi 6y ago
  YMMV, but most of our in-house applications use a few of the Aspose .NET libraries. Many of them are written to interact with our billing and document management systems (primitive VCS). I have written a few applications and most of them would be useless outside of our environment. I have released some PowerShell scripts to an industry specific forum, though. The biggest barrier to releasing our applications as open source are organizational. It would take a number of approvals to do so and our developers would have to review the code first. We have a small development team with a large backlog of work; it’s hard to argue that they should spend time to do this instead of a higher priority task.
whereistimbo 6y ago
> there are checks to ensure that expletives and comments that might cause severe repercussions (i.e. political statements) are not inserted Related: In the past, after Microsoft was forced to release Hyper-V linux driver source code under GPL, someone noticed 'naughty phrase' in magic number that Hyper-V used, which is '0xB16B00B5' or 'BIG BOOBS', Microsoft apologized afterwards [0] [0]: http://www.networkworld.com/community/blog/microsoft-code-contains-phrase-big-boobs-yes-really http://www.networkworld.com/community/blog/microsoft-code-co...

fsflover 6y ago

> but the problem is that they have used a third-party library where they cannot legally release because they simply don't have the rights to it. Just release everything else. Someone can write their own library for that or maybe even find a replacement in the open-source world.

ghaff 6y ago
Unless it's something wildly popular, to a first approximation, no one is going to go to the effort to get a discontinued game or other software into a usable state given missing libraries, build systems, developer docs, etc. And, as parent noted, it's still quite a bit of work to open source proprietary code even if a company has a genuine interest in doing so. I have first-hand knowledge of situations where a company wanted/needed to open source acquired code and it took a good year of concerted effort to do so.
- colonwqbang 6y ago
  In the second paragraph of the article the author describes how some dependencies of the application were replaced by open-source libraries like SDL. There are also many more examples of this happening. So the assertion that "nobody" would do it is wrong. If the application is interesting, people will find find a way to run it on modern hardware. It's not an excuse not to open-source what you can of your code. This line of excuses is just weak. Either release the code or keep it proprietary, that's your decision as owner. Just spare us the silly excuses and trying to make it seem like your company would really really like to open-source if only it wasn't for that tiny detail of blah...
  - johannes1234321 6y ago
    Getting rid of third party's code often isn't as easy as removing a folder and be done. Sometimes third party code is deeply integrated and was patched and can't be isolated or it might be the core component/core engine where the missing make aThe reminder almost useless. Also some vendors put their APIs behind an NDA, thus you not only have to remove the API, but also rework the calling code. (Just for open sourcing fighting whether the NDA is legally clair is quite some effort ...) This also becomes fun if you worked with external contractors, who committed all over the code and the agreement doesn't cover releasing the code. And then there are still all the other things in open sourcing (making sure comments are appropriate, naming is appropriate, ...) And then you have IP besides the source, in artwork where designers often have some rights, copyrights, trademarks ... And after all that the "fear" on your reputation, if one fears the code might seem of low quality, which might reflect bad. (Whether it's truly bad doesn't really matter, a few blog posts or youtube videos of somebody taking worst parts can harm reputation) It's all simpler, if you plan on doing that eventually from the start, but notable effort for any serious project after the fact.
    - colonwqbang 6y ago
      It seems unwise to let control of your product degrade to the point where you cannot draw a line between code you own yourself and encumbered/external code. It should be possible to avoid with proper planning. Still, you're probably right that it is a common situation. Your other examples mostly seem to boil down to "we were not willing to commit the necessary resources to do it". Which is fine, of course.
maccard 6y ago
If you don't have the rights to release it you likely don't have the rights to redistribute the api either, so you need to strip that out.
- deleted 6y ago
  [deleted]
- syshum 6y ago
  Well I hope then that Google wins against Oracle and we can finally say API's are not copyrightable...
  - deleted 6y ago
    [deleted]
  - maccard 6y ago
    Even if that is the case, there's a difference between an api being copyright protected, and an api being redistributable
    - syshum 6y ago
      In what way exactly? Copyright law is the only method a person has to control how it redistributed, if there is no copyright on the API then no one has the legal authority to prevent redistribution.
      - maccard 6y ago
        Contract law. I'm not aware of it having been tested, but a contractual obligation not to distribute something is not the same as something not being copyrighted. See the post on HN yesterday about atlassian not allowing performance comparisons as part of their TOS.
      - zinekeller 6y ago
        Note: US law, obviously (these points are moot in EU due to strong laws for interoperability). Contracts can legally bind the developer/s with this, more so if it is a corporate entity. Even if Google wins this case and the APIs cannot legally acquire copyright protection, the third-party can sue the developer/s for disclosing trade secrets. The code legally is clean (IP-wise) at this point, but the developer/s have broken a contract with the third-party provider in doing so, and they can sue those developer/s (however, any users of the released code are protected since they are not the signatories/parties to the contract).
Thaxll 6y ago
As if it was just that easy to remove all part of third party code ... For example removing a physic engine from a game is pretty much "impossible".
- Ace17 6y ago
  It depends on how the physics engine has been integrated into your game/engine. The book "Game Coding Complete" shows how to isolate a 3rd-party physics engine so you can switch implementations. Of course, every physics engine behaves a little differently from the others, so, if you game is physics centered (pinball, racing), switching implementation might result in a slightly different game - but having the core of your game depends on the implementation details of some 3rd-party library might not be a good idea anyway. In general, the more you sprinkle your code with dependencies to 3rd party libraries, the less control you have over the resulting product. Your point still stands, though, for some very low-level "utility" libraries like boost or the STL, or any standard library replacement , and more generally, libraries holding "vocabulary" types.
- deleted 6y ago
  [deleted]
jandrewrogers 6y ago
There are a surprising number of cases where it is extremely unlikely that a library is replaceable even if the use case is popular and there is no restriction on making an open source replacement. The overhead cost of open sourcing software can be high, which must be offset by a realistic expectation that value will be created by open sourcing it. There are two common cases not considered here of which I've seen several examples of libraries in my world. First, replacing the library requires extremely high/rare expertise and several man-years of development to implement a basic version. These never get replaced in open source because the level of individual investment is extraordinary; these libraries only get built when a company invests a few million dollars hiring one of the handful of people that know how to write one over years, which is rare and at which point they want to own it. The barrier to open source MVP is simply too high. Even worse, in some cases the licensed version becomes unavailable/unsupported because the person that designed it moves on but at least there is an incentive to spend a lot of money to remedy that. Second, replacing the library requires computer science that has no description in literature. I've seen teams of CS PhDs spend years trying to clean room equivalent libraries with little success when there are few hints in existing computer science literature how the original library capability was even achieved. They might be able to buy a license to the original library but many times that is cost prohibitive (millions of dollars) or not available at all (licensing restrictions). Not every application has a library dependency with these properties but it isn't that rare either. These libraries are used for good reason and sometimes provide central functionality without which the rest of the source code is relatively low value.
- matheusmoreira 6y ago
  > the library requires extremely high/rare expertise and several man-years of development to implement > the library requires computer science that has no description in literature Can you mention examples of such cases?

MayeulC 6y ago

> but the problem is that they have used a third-party library where they cannot legally release https://github.com/id-Software/DOOM https://github.com/id-Software/DOOM The DOOM source code was released without sound support due to this: > The bad news: this code only compiles and runs on linux. We couldn't release the dos code because of a copyrighted sound library we used (wow, was that a mistake -- I write my own sound code now), and I honestly don't even know what happened to the port that microsoft did to windows. This isn't always a true dichotomy. Any code is better than none, you don't have to release all of it to make a difference (especially if the closed-source library is provided as a shared object). The code could be provided in a non-functionning state, it would already be a lot more helpful than binary patching while relying on disassemblers. A closed-source library can be worked around (stripping functionality), replaced, re-implemented, linked against a blob, reverse-engineered, etc.

zinekeller 6y ago
I actually used Doom as an example of software that has received a great (it might be even the greatest) community help. However, this comment (https://news.ycombinator.com/item?id=25622021 https://news.ycombinator.com/item?id=25622021) has succintly described further the issues of open-sourcing a previously closed-sourced software. One of the most important point here is the fact that some software code are not organized could have a surprise third-party code which required intensive audits. Obivously, in some cases it is simply not economical to do such auditing.

blablabla123 6y ago

That might be quite a blocker for closed-source commercial apps that are distributed to the user. On the other hand in-house apps and web apps usually don't suffer this problem from what I've seen. Most of the time open source libraries are strongly preferred and even if not, the closed sourced licenses for dependencies can easily be obtained by the intended user oftentimes. (At least frontend dependencies need to be MIT or BSD licensed anyway)

tjalfi 6y ago
YMMV, but most of our in-house applications use a few of the Aspose .NET libraries. Many of them are written to interact with our billing and document management systems (primitive VCS). I have written a few applications and most of them would be useless outside of our environment. I have released some PowerShell scripts to an industry specific forum, though. The biggest barrier to releasing our applications as open source are organizational. It would take a number of approvals to do so and our developers would have to review the code first. We have a small development team with a large backlog of work; it’s hard to argue that they should spend time to do this instead of a higher priority task.

whereistimbo 6y ago

> there are checks to ensure that expletives and comments that might cause severe repercussions (i.e. political statements) are not inserted Related: In the past, after Microsoft was forced to release Hyper-V linux driver source code under GPL, someone noticed 'naughty phrase' in magic number that Hyper-V used, which is '0xB16B00B5' or 'BIG BOOBS', Microsoft apologized afterwards [0] [0]: http://www.networkworld.com/community/blog/microsoft-code-contains-phrase-big-boobs-yes-really http://www.networkworld.com/community/blog/microsoft-code-co...