[HN Gopher] Unity's Open-Source Double Standard: The Ban of VLC
___________________________________________________________________
Unity's Open-Source Double Standard: The Ban of VLC
Author : 2pEXgD0fZ5cF
Score : 921 points
Date : 2024-01-12 07:05 UTC (15 hours ago)
(HTM) web link (mfkl.github.io)
(TXT) w3m dump (mfkl.github.io)
| DeathArrow wrote:
| They still can publish their assets outside of the Unity store.
| Users can download them and install them in Unity. But I agree
| it's not a nice move from behalf of Unity.
| nacs wrote:
| And in the linked article, VLC mentions they have now done that
| -- they have their own site to download the plugins.
| chii wrote:
| What's the rational for not allowing LGPL code on the unity
| store? It makes no sense for the ban imho (tho i m not very
| familiar with unity store's model so i might just be missing
| something).
| paulmd wrote:
| intredasting, they rather explicitly appear to be tilting
| against viral licensing:
|
| > 5.10.4 Provider represents and warrants that its Assets shall
| not contain (a) any software licensed under the GNU General
| Public License or GNU Library or Lesser General Public License,
| or any other license with terms that include a requirement to
| extend such license to any modification or combined work and
| provide for the distribution of the combined or modified
| product's source code upon demand so that Customer content
| becomes subject to the terms of such license; or (b) any
| software that is a modification or derivative of any software
| licensed under the GNU General Public License or Library or
| Lesser Public License, _or any other license with terms similar
| thereto so that Customer content become subject to the terms of
| such license._
|
| LGPL doesn't impose combined redistribution requirements, does
| it? They're just tilting against that whole ecosystem
| specially. And if you apply the same standard as LGPL, MIT/BSD
| are basically the same right? Probably CDDL falls in too?
| that's absolutely a crazy thing but it's pretty straightforward
| in the licensing agreement.
|
| No, no, they got it all wrong:
|
| "not, invented here!"
| adrian_b wrote:
| LGPL is a regular license, it is not a viral license.
|
| GPL is a viral license.
|
| The GNU glibc uses LGPL and almost any program run on a Linux
| system uses glibc, regardless in what programming language it
| has been written, at least for the system calls. If LGPL had
| been a viral license too, all programs would have been
| affected.
| ghusbands wrote:
| Doesn't the LGPL give users the right to replace the LGPL
| part with a modified library of their choice? It seems
| doubtful that users can modify downloaded Unity apps at
| their leisure, so that would mean that LGPL cannot be
| supported on Unity, wouldn't it?
|
| Though then it would seem that LGPL libraries on almost any
| app store are being used against their license terms, so I
| must be wrong.
| adrian_b wrote:
| The obvious way to comply with LGPL is to link
| dynamically the LGPL libraries, even if everything else
| is linked statically.
|
| I am pretty sure that the Unity executables link
| dynamically glibc anyway.
|
| The alternative is to do the static linking in 2 steps.
| First link everything else into a big ELF object file,
| then do the final linking of the LGPL libraries.
|
| For compliance with the LGPL, it is enough to provide
| access to the big binary object file, so that a user may
| relink the possibly modified LGPL libraries, if desired.
|
| A dynamically-linked executable and an object file that
| needs a final static linking step with additional
| libraries have almost identical content and they provide
| equivalent information.
| pzo wrote:
| Sometimes even dynamic linking might be not enough - on
| iOS you can build dynamic frameworks that are dynamically
| linked but they are signed with developer provisioning
| key when distributed via App Store. AFAIK there is not
| other way for end user to swap such dynamic
| framework/library unless developer will provide source
| code or object files or compiled code (e.g. in other
| dynamic framework that links dynamically to such LGPL
| code). Not sure about jailbroken iPhones.
|
| Also for more complicated iOS projects (that require iOS
| capabilities e.g. in-app-purchase, push notifications,
| app pay, icloud etc.) end user would need to have a paid
| apple developer account to create and sign build.
| swiftcoder wrote:
| > Though then it would seem that LGPL libraries on almost
| any app store are being used against their license terms,
| so I must be wrong.
|
| You are not wrong. LGPL does require that you provide
| users the ability to link against a modified version of
| the LGPL library. It is a requirement that has been
| rather honoured in the breach in this age of appstores
| palata wrote:
| > LGPL does require that you provide users the ability to
| link against a modified version of the LGPL library.
|
| That's correct for LGPLv3, but I believe LGPLv2 is more
| nuanced.
|
| With LGPLv2, I don't think it requires that _you provide
| the ability_. It has to be possible if you get access to
| the executable (which may require that you jailbreak your
| device, for instance). For instance, it is my opinion
| (not legal advice) that it is fine to use an LGPLv2 Java
| library in a proprietary Android app, because you can
| technically go replace the class files corresponding to
| the LGPLv2 library in your apk. It 's not easy to do
| (unlike swapping a dynamic library), but it is possible.
| rerdavies wrote:
| > can technically go replace the class files
| corresponding to the LGPLv2 library in your apk
|
| APKs in the Android app store MUST be cryptographically
| signed. So, it is impossible.
|
| The only practical solution that an LGPL license provides
| for Android apps is to fall back to the viral GPL
| license.
| maple3142 wrote:
| But you don't have to publish that modified apk to Play
| Store. You can just sign it with your own key and install
| the apk manually, no root needed.
|
| I know there are some apps that do its own cryptographic
| signature verification on their own, but most apps don't
| do that, so replacing a LGPL library in an APK is
| actually feasible in most cases. It is not hard to do so
| either.
| palata wrote:
| They must be signed to be on the store, but I don't think
| it's impossible to run unsigned apks on the device (maybe
| you need the developer mode, though).
|
| But even then, wouldn't that count like tivoization?
| LGPLv3 says you need to provide instructions to replace
| the lib, but LGPLv2 does not. Couldn't I say "I honor the
| LGPLv2, because it would be technically possible to
| update the library, but unfortunately for you it is
| behind some tivoization that you would need to break
| first"?
| paulmd wrote:
| That is irrelevant, look at the way the clauses are
| structured:
|
| > (b) any software that is a modification or derivative
| of any software licensed under the GNU General Public
| License or Library or Lesser Public License,
|
| > or any other license with terms similar thereto so that
| Customer content become subject to the terms of such
| license.
|
| it's not a question of terms similarity in that clause,
| it literally forbids any usage of GPL or LGPL by name.
| These licenses are "name banned", not just by "features".
| You can't have GPL or LGPL, nor can you require clients
| to sublicense you to GPL/LGPL for your program to
| operate, or any other license that has similar
| propagating terms to sub-licensed entities.
|
| Obviously you can turn the world on "terms similar", h265
| user/device licensing or whatever isn't terms similar
| here. But just by the plain text it's very obviously a
| direct swipe at GPL and viral licensing, they're banned
| by name, at minimum they probably want to see BSD/MIT I
| guess.
|
| Article isn't wrong that's a crazy-ass term.
| paulmd wrote:
| This isn't a linguistic disagreement, LGPL and similar
| licenses are literally forbidden by the direct plain text
| of the agreement.
|
| > (b) any software that is a modification or derivative of
| any software licensed under the GNU General Public License
| or Library or Lesser Public License, or any other license
| with terms similar thereto so that Customer content become
| subject to the terms of such license.
| adrian_b wrote:
| The complaint was not that it is not true that they have
| not complied with the agreement, but that this rule is
| only selectively enforced and that nobody truly complies
| with it.
|
| Moreover, the rule has no rational reason, because unlike
| with GPL, compliance with LGPL is very easy to achieve,
| even for proprietary programs.
| rerdavies wrote:
| The rule is completely rational. It is impossible to use
| LGPL-licensed components on the Android app store or
| Apple app store without becoming infected with the full
| GPL. (As extensively discussed throughout this thread).
| cozzyd wrote:
| Sounds like Apple and Google should fix their broken app
| stores then.
| lmm wrote:
| > LGPL is a regular license, it is not a viral license.
|
| > GPL is a viral license.
|
| The LGPL's level of "virality" is small, but nonzero - it
| imposes requirements on a larger program of which you use
| LGPL code as a part. Those requirements are much smaller
| than the requirements imposed by GPL code in the same
| circumstances, but they are real, and much more substantial
| than e.g. including a copyright notice.
|
| > The GNU glibc uses LGPL and almost any program run on a
| Linux system uses glibc, regardless in what programming
| language it has been written, at least for the system
| calls.
|
| glibc has an explicit linking exception for programs using
| its public interface.
| davexunit wrote:
| Calling a license "viral" is a gross pejorative intended to
| discourage copyleft.
| paulmd wrote:
| okay
| MaxBarraclough wrote:
| At the risk of seeming pedantic, the proper term is
| _copyleft_ , not _viral licensing_. If memory serves, _viral
| licensing_ has its origins in Microsoft fear-mongering
| (predating the modern positive use of _viral_ , as in _go
| viral_ ).
|
| > LGPL doesn't impose combined redistribution requirements,
| does it?
|
| It does, in that if you modify the source-code of an LGPL-
| licensed library and distribute the binary, you are required
| to also distribute the source (i.e. the source of your
| modified version). Your modified source must also use the
| LGPL licence.
|
| If you distribute an unmodified binary for an LGPL-licensed
| library, you must also provide access to the unmodified
| source. (This isn't to say you need to bundle it into the
| same archive file.)
|
| It differs from the vanilla GPL in that an LGPL-licensed
| library permits you to dynamically link to it from
| application code that doesn't need to use any particular
| licence.
|
| (This is at least the gist of the matter as it applies to
| application code. This isn't legal advice, I'm not a lawyer,
| etc.)
|
| See the final point on this page from the FSF (authors of the
| GPL and LGPL) -
| https://www.fsf.org/bulletin/2014/fall/common-gpl-
| misconcept...
| rerdavies wrote:
| At the risk of seeming pedantic, who are you to decide
| whether viral licensing or copyleft is the proper term?
| MaxBarraclough wrote:
| It's not just my preference, anyone familiar with this
| area of copyright law recognises _copyleft_ as its
| standard name. _Viral licensing_ is, as I said, a snarky
| pejorative. [0][1]
|
| It's also less precise. Proprietary licenses can be
| 'viral' too. DRM libraries, for instance, may require
| that application source code not be made publicly
| available.
|
| > At the risk of seeming pedantic
|
| Parroting others in this way comes across as juvenile and
| antagonistic.
|
| [0]
| https://en.wikipedia.org/wiki/Copyleft#Viral_licensing
|
| [1] https://en.wikipedia.org/wiki/Viral_license
| paulmd wrote:
| > juvenile and antagonistic.
|
| honestly you are over-reading and projecting here
| charcircuit wrote:
| The rational is that you should be able to just install any
| asset from the store in your game and be good to go. With an
| LGPL asset now you have to let customers be able to edit that
| addon and rebuild your game with it which would be a pain, and
| most developers do not want to give out the unity project
| files.
|
| Having a simple licensing story for assets on the store lets
| users have trust in whatever they see they can use in their
| game worry free.
|
| Edit: Removed bit about LGPL applying to the original code
| because of static linkage because it was incorrect and
| distracting from my point
| adrian_b wrote:
| What you say is not correct.
|
| Only linking with a GPL library makes GPL applicable to the
| whole program.
|
| This is the difference between LGPL and GPL. LGPL is a normal
| license that applies only to the library.
|
| Since glibc uses LGPL, if your theory had been true than
| almost all programs run on a Linux system, regardless of
| their origin, would have been covered by LGPL.
| charcircuit wrote:
| The LGPL code gets statically linked with the rest of your
| code which means that you have to provide the project files
| in order to be able to change the LGPL code.
| adrian_b wrote:
| No, you do not have to provide any project files, even
| when everything is linked statically.
|
| Static linking can be split into two linking steps, first
| everything except the LGPL libraries can be linked into a
| big ELF object file, which no longer contains any
| information about the internal structure and the internal
| symbols, exactly like an executable file. The only
| difference between such an object file and an executable
| is that it contains unresolved external references, like
| a dynamically-linked executable.
|
| Then in the second and final linking step, the big binary
| object file is linked with the LGPL libraries.
|
| For compliance with LGPL it is enough to offer access to
| the big binary object file for the users who would want
| to replace the LGPL libraries.
| charcircuit wrote:
| Please do not forget that we are talking about Unity.
| Unity doesn't let you split up linking like that. All the
| game and asset codes gets mixed together in a single
| step. Needing to split out and rig together some hacky
| solution is the reason why they don't want it in the
| assert store. As I said in my original comment Unity
| wants assets to be low friction to add to your project.
| shakow wrote:
| > With an LGPL asset now you have to let customers be able to
| edit that addon and rebuild your game
|
| > so now your game code is also under the LGPL and you have
| to publish your game code.
|
| AFAIK, that's only true of the GPL, not the LGPL.
| palata wrote:
| As a side note, I believe that LGLv3 says that you have to
| provide instructions about how to do it, but with LGPLv2 is
| just has to be technically possible if you have access to
| the binary.
| larschdk wrote:
| My guess; Unity doesn't want LGPL code in component they re-
| distribute, because the responsibility to comply with the
| license requirements falls on them, since they are the ones
| redistributing. It's not that they can't, but they wont take
| that responsibility, which is understandable. They would
| basically need to audit every component to ensure that the end
| user can build and replace LGPL parts with their own.
| toyg wrote:
| Not really. They could just distribute things anyway, and
| simply invoke the license-termination clauses as soon as any
| infringement is detected by claimants - similarly to how (I
| expect) they would treat claims of copyright infringements on
| game assets.
|
| They are just being obtuse - which looks fishy when coupled
| with VLC's claims that they wouldn't allow them back in _even
| if all LGPL code was removed_. They probably don 't want
| competition for some component.
| captainmuon wrote:
| I'd say it is even debatable whether Unity is really re-
| distributing in the sense of the LGPL or merely hosting.
| Redistribution is something between licensor and licensee,
| your web hoster or your telecom is not involved.
|
| But I guess that's another thing they don't want to test in
| court and it's easier to say they don't want it.
| larschdk wrote:
| The LGPL license doesn't work that way. The rights that it
| establishes follows every time you transfer the work
| between legal entities. If I transfer the work to you, I
| need to extend the rights granted in the license to you. I
| can't expect others to do it for me.
| maratc wrote:
| I think your guess is correct. GPL/LGPL is a contract that
| puts certain obligations on all parties; just by being a
| redistributor, Unity now becomes a party to a contract they
| never signed or even intended to sign.
|
| It's easier for them to refuse to be a party to that contract
| by not allowing any software under that license on their
| property to begin with.
| agsnu wrote:
| My guess is that they want packages on the Unity store to be
| usable on all platforms they support.
|
| For example, if you build an app for iOS or visionOS, you have
| to distribute it via Apple's stores, and there are technical
| barriers (code signing, DRM) that get in the way of an end user
| being able to exercise their right to replace LGPL components
| with modified versions. I mention this example because there
| was a big tie up for Unity and visionOS announced with the
| Apple Vision Pro last summer, but presumably the same applies
| to Unity games on consoles etc as well.
|
| I can see why from Unity's perspective it is cleaner to just
| forbid LGPL entirely, that way it is harder for their customers
| to mistakenly violate licenses.
| palata wrote:
| > there are technical barriers (code signing, DRM) that get
| in the way of an end user being able to exercise their right
| to replace LGPL components with modified versions
|
| I wonder if that is an issue for LGPLv2. Pretty sure that for
| LGPLv3, the distributor would have to give instructions
| explaining how to do it (which they could not do), but LGPLv2
| does not require that, right?
|
| As in, wouldn't code signing and DRM count as some kind of
| tivoization?
| mihaaly wrote:
| Would it worth a try reporting other LGPL violations to Unity -
| as drawing attention to violations of their own 5.10.4 of
| Provider agreement - in a documented manner? Just to see how
| they proceed.
| rendall wrote:
| Why would Unity do this?
| firtoz wrote:
| Most of the good people have left Unity or have been laid off.
| Whoever remain are likely ill equipped to deal with anything.
| So I see these kinds of decisions as the death throes of the
| company.
| Diti wrote:
| https://www.theguardian.com/games/2023/sep/12/unity-engine-f...
|
| Remember this?
|
| I wonder what's going on in the Unity executive's heads right
| now.
| firtoz wrote:
| "$$$$$$$$$$$$$$$$$$$$$$$"
| ecuzzillo wrote:
| The CEO has been fired since then.
| usea wrote:
| Incompetence is the most likely explanation.
| hiccuphippo wrote:
| If you see them release their own video add-on in the next few
| months then there's the reason.
| loa_in_ wrote:
| That makes the name Unity very ironic right now.
| toyg wrote:
| Can anyone explain what looks like complete idiocy here? Why
| would the LGPL be so "radioactive" from Unity's perspective?
|
| Looks like yet another faux pas by a company bent on self-
| destruction.
| reactordev wrote:
| Anything derivative or including LGPL code assumes the license.
| It prohibits commercial use unless you also adopt LGPL.
|
| https://fossa.com/blog/open-source-software-licenses-101-lgp...
| Qwertious wrote:
| LGPL is specific to the library. A proprietary application
| can ship with an LGPL library, as long as the _library_ hasn
| 't shipped with proprietary modifications.
| reactordev wrote:
| But Unity can't do that because it transpiles code on
| build... simply linking using LD wouldn't make you have to
| adopt. Any modifications would, and would have to be
| published in source code form.
|
| This is why, in Unity, LGPL is the black plague.
| justinclift wrote:
| Why would transpiling mean anything special?
| thecatspaw wrote:
| unity only does transpiling for C# to native code if you
| enable it in your project. it cannot transpile the
| (presumably) linked native library so this shouldnt be an
| issue here
| reactordev wrote:
| Consoles operate a bit differently. Sometimes it's
| necessary to binary patch. Breaking LGPL.
| debugnik wrote:
| These VLC packages only had assets for Windows, UWP and
| Android.
| boxed wrote:
| You are confusing GPL with LGPL.
| reactordev wrote:
| "Generally, dynamic linking of LGPL code is considered best
| practice, as static linking makes meeting the license
| requirements more complicated. While it is possible to
| comply with LGPL code that is integrated into proprietary
| code as a statically linked library, it requires more
| effort. There is a kind of safe harbor for using LGPL code
| as a dynamically linked library; for statically linked
| libraries, a distributor must offer access to not only the
| library's source code, but other information or materials
| necessary to rebuild the program."
|
| This makes IL2CPP kinda hairy in Unity-land. Since it's
| being modified to static-link, it must be released as
| source. So no, I don't think I'm confused at all.
| adrian_b wrote:
| LGPL has nothing to do with IL2CPP, even when the library
| is statically linked.
|
| Regardless how Unity might transpile their applications,
| they must be combined with a LGPL library only after
| everything has been converted into binary object files,
| by the linker.
|
| In order to comply with the LGPL requirement that the
| user must be able to rebuild the application after
| possibly modifying the LGPL library, the only thing that
| must be provided is the linker command line that creates
| the final static executable.
|
| No other information about the proprietary source files
| or about how they are compiled needs to be provided.
|
| If it is desired that no function names should be leaked
| from the proprietary code, everything except the LGPL
| libraries can be pre-linked into a big binary object file
| without information about the internal symbols, which can
| be linked with the LGPL libraries only as a final step
| for generating the statically-linked executable.
|
| In this way, there is absolutely no difference in the
| information provided when static linking is used and when
| dynamic linking is used.
|
| The claim that dynamic linking is necessary with LGPL
| libraries is completely wrong, because linking them
| statically, but only after linking the other libraries,
| is completely equivalent.
| charcircuit wrote:
| >In order to comply with the LGPL requirement that the
| user must be able to rebuild the application after
| possibly modifying the LGPL library, the only thing that
| must be provided is the linker command line that creates
| the final static executable.
|
| This isn't possible with IL2CPP.
| Karliss wrote:
| IL2CPP should affect only .NET libraries, it won't do
| anything to included native code .dll,.so libraries. I
| would expect that in 80% of cases the LGPL librararies
| you might want to use are actually written in C or C++ so
| they would still be dynamically linked even with IL2CPP.
| justinclift wrote:
| Probably overly cautious legal advice from lawyers who don't
| know how much LGPL stuff is already in the store and used by
| Unity itself.
| lupusreal wrote:
| It is as you suspect; Unity is run by idiot suits who don't
| understand their own business.
| jamesholden wrote:
| From the article:
|
| _After months of slow back-and-forth over email trying to find a
| compromise, including offering to exclude LGPL code from the
| assets, Unity basically told us we were not welcome back to their
| Store, ever. Even if we were to remove all LGPL code from the
| Unity package._
|
| _Where it gets fun is that there are currently hundreds if not
| thousands of Unity assets that include LGPL dependencies (such as
| FFmpeg) in the Store right now. Enforcement is seemingly totally
| random, unless you get reported by someone, apparently._
| CodeCompost wrote:
| Weird pivot in the middle of the article where all of a sudden
| they're promoting a product. Is this an ad disguised as a
| clickbait article?
| blauditore wrote:
| I wonder if the license was the actual reason for the ban, or
| some shenanigans like this article, trying to sneak in ads
| somewhwere.
| boomboomsubban wrote:
| It's vlc, I doubt it.
| mort96 wrote:
| Are you suggesting that VLC is lying about the communication
| from Unity, including faking the screenshot (or lying by
| omitting other e-mail)? Or are you suggesting that Unity is
| lying to VLC about the reason for the ban?
| loup-vaillant wrote:
| Step 1: we're banned from the store!
|
| Step 2: we have our own store now!
|
| That's not a weird pivot, that's what you do when a company you
| depend on no longer wants to do business with you.
| fwn wrote:
| It's not even competition, as Unity seems to have decided to
| "deprecate" the Unity Store for VLC. /s
| PUSH_AX wrote:
| "depends on" is a bit strong.
| tankenmate wrote:
| Have you seen VideoLAN's revenue? What percentage of their
| revenue came via the Unity Store?
| PUSH_AX wrote:
| They're a non profit organisation. They existed before
| the Unity store and they are existing after the Unity
| store. They did not _depend_ on Unity.
| tankenmate wrote:
| Non profit doesn't mean all the employees work for free.
| Your statement is the equivalent of saying "The Red Cross
| don't need money, they're a non profit!"
| PUSH_AX wrote:
| Not sure how that relates to them "depending on Unity"?
| is really clear that they never have, nor do they now.
| tankenmate wrote:
| "is really clear that they never have (depended on
| Unity)"; I'd be happy to come to the same conclusion, IF
| there is evidence.
|
| But most of your comments seem to be conclusions looking
| for evidence rather than the other way around.
| PUSH_AX wrote:
| Equally one possible line of reply you could have offered
| is some evidence that they were dependent. When neither
| side can produce evidence it seems fair to me to fall
| back on some clear deductions, which I won't repeat.
|
| Honestly this debate seems like a waste of time for both
| of us. I'll leave it here, and I hope you have a good
| day.
| tankenmate wrote:
| You claimed they weren't dependent, not me. My comment,
| paraphrased, was "How can you be sure without evidence?";
| I don't know if they are dependent, not enough
| information.
|
| I hope you have a good day too!
| uxp8u61q wrote:
| The evidence is that VideoLAN still exists months after
| getting banned by Unity. If they "depended" on Unity
| they'd be bust by now.
| alexdns wrote:
| I dont think the VLC team has been caught in multiple
| scams like the red cross tho ?
| tankenmate wrote:
| Your statement is completely non sequitur.
| master-lincoln wrote:
| How so? Their statement was that not that VideoLAN does
| not need money, the statement was they do not depend on
| the Unity store to get enough money. Nobody claimed non
| profit means working for free or even went into that
| direction. The statement "They did not _depend_ on
| Unity." is not equivalent of saying "The Red Cross don't
| need money, they're a non profit!". Or which statement
| did you refer to?
|
| Please be less enraged and try to understand the
| arguments of others in discussions.
| tankenmate wrote:
| I'm not enraged, my point was simple; without knowing
| what VideoLAN's revenue looks like you can't say for
| certain that VideoLAN don't actually depend on it. Say
| for example VideoLAN got 75% of their revenue from the
| Unity Store and then they got banned; I would say that is
| a case of dependence. Without such knowledge it is very
| difficult to say with certainty whether VideoLAN is
| dependent on their products being available on the Unity
| Store.
|
| Nothing to do with being "enraged"; in discussions it
| generally doesn't help to attribute motivation without
| evidence.
| master-lincoln wrote:
| Sorry for attributing motivation without evidence, I
| regret that and think you are right on this point.
|
| Now I got your point concerning the dependence. That was
| not clear to me before you elaborated and I don't see how
| I could have inferred that.
|
| It is highly unlikely though that this integration into a
| game engine made any significant revenue in its 3 years
| of existence if you ask me. The integration is also still
| available, just not distributed via Unity store.
|
| As VideoLan is a non-profit I tried to find info on their
| income to get a bigger picture, but failed to find that.
| Supermancho wrote:
| > without knowing what VideoLAN's revenue looks like you
| can't say for certain that VideoLAN don't actually depend
| on it.
|
| This is a matter of how someone might interpret
| "depends".
|
| If you meant "effectively will cease to exist", that is
| incorrect.
|
| If you meant that VideoLAN depends on Unity the same way
| I depend on the 5 dollars in my pocket to be
| fungible...VideoLAN still exists without Unity, same as I
| exist without the 5 dollars in my pocket.
|
| There's nothing more to it, afaik.
| glenstein wrote:
| Right, I think this is a nothingburger - they 'depend' in
| the sense of leaving it up to Unity to honor a defined
| set of responsibilities on their side of a relationship.
| I think there was no need to get into whether this posed
| any sort of existential threat to VLC.
| DirkH wrote:
| Nonprofits die all the time because they run out of money
| red_trumpet wrote:
| Just as strong as "dependency" is usually used in software
| engineering, not? They swapped out a dependency, so now
| they don't depend on the unity store any longer.
| mort96 wrote:
| "Rely on" then? Regardless, I think their point was clear.
| nebulous1 wrote:
| I agree that it came off as a bait and switch. Having looked a
| bit deeper, the plugin is open source and you can download,
| compile and distribute it for free. They charge for the
| precompiled binaries that you can get in the Unity Store (now
| videolabs store).
|
| If we were already aware of all this then this wouldn't have
| come off in the same way. The problem is that due to the way it
| was written I think most people expected the plugin to be free
| on the store. Personally I think it just could have noted that
| the general interest section of the article was finished when
| they segued into the store announcement.
|
| Anyway, assuming everything is as they say then it seems pretty
| clear that Unity have some other reason for banning it, most
| likely commercial.
| softfalcon wrote:
| I get how that can seem very jarring. On the other hand, VLC
| has single handedly solved the "how do I play all the world's
| weird ass video/audio files" for free with no gotcha's for
| years now.
|
| I think they're more than entitled to try and advertise a
| little bit. It's not like they're doing anything evil asking
| for some money. You can still go download all the code yourself
| and build it manually for free if you want.
| jasonjmcghee wrote:
| Look, I'm frustrated with Unity as a company too, but a hit piece
| as a product announcement?
| jovial_cavalier wrote:
| It's not a hit piece if the allegations are true.
| spywaregorilla wrote:
| Not true. Folks love to print stories that are true but not
| noteworthy. And then they post a note about the things that
| were noteworthy but old news.
| jovial_cavalier wrote:
| That doesn't make it a hit piece. A hit piece is when you
| are slandering someone unfairly, not publishing something
| un-noteworthy.
|
| I suppose I don't know whether TFA is being unfair, but I
| have no reason to doubt what they say, and calling this a
| hit piece is a bit of a leap for me.
| mayli wrote:
| The ban of "VLC for Unity integration".
| numpad0 wrote:
| Didn't Unity have its own included media stack?
| martz wrote:
| they do but it's fairly limited.
| ghusbands wrote:
| The LGPL gives end users the right to replace the LGPLed part
| with a modified version, and users presumably cannot alter parts
| of a downloaded Unity app. So it does seem that software using an
| LGPL library cannot be distributed on Unity or most any modern
| app store and still be in compliance with the LGPL.
|
| It's not viral, but it does give users rights that aren't natural
| under the app store distribution model.
| larschdk wrote:
| It's not impossible to comply with LGPL under the app store
| model, but the responsibility falls on the distributor, which
| is Unity in this case. I can understand that that is something
| they are not able or willing to do. This doesn't mean that they
| can't comply with LGPL for components included in Unity itself.
| I don't see any double standard here.
| tankenmate wrote:
| You're right, but there is the large counterpoint of the fact
| that Unity is doing exactly that for other software licenced
| under the LGPL.
| larschdk wrote:
| Very different. They can do that, because they are in
| control of the components and build process. That's much
| harder for someone else's deliverables.
| captainmuon wrote:
| I can give you a right, but that doesn't mean you're neccessary
| able to excercise that right. I can allow you to drive a tank
| on my property, but you probably can't afford one, and it would
| be banned by laws.
|
| I'm curious, does the LGPL state explicitly that the licensor
| guarantees that the licensee can excercise their granted rights
| in practice? There can always be external circumstances
| restricting what I can do.
|
| Or is it more like: The licensee (the unity package developer)
| can only use the code (VLC) if _they_ guarantee that the sub-
| licensee (the package user or the end user) can excercise all
| their rights with no external conditions?
|
| Edit: I think LGPL 3 actually does demand this, in the context
| of preventing "tivoisation". However, libvlc is licensed under
| LGPL 2.1 as far as I can see.
| ghusbands wrote:
| IANAL, but when it comes to contracts/licences, intent, good
| faith and fair dealing are important. Allowing someone a
| right that you know cannot be exercised would likely fail
| under all three of those. Your intent is not for them to have
| that right, you're not acting in good faith in claiming they
| have the right and you're misrepresenting the possibility.
|
| The law is not as prescriptive on the exact text as many
| programmers think. What typically matters in court is what
| people mutually understand/understood terms to mean, and
| clear attempts to mislead are typically judged against the
| one doing the misleading.
|
| So, yes, if it went to a court that was otherwise supportive
| of (L)GPL, providing (L)GPL code on a platform on which users
| certainly cannot exercise their rights would likely be a
| failure to provide and hence abide by the licence.
| troupe wrote:
| > I'm curious, does the LGPL state explicitly that the
| licensor guarantees that the licensee can excercise their
| granted rights in practice?
|
| It feels like such a requirement would mean you would have to
| test each potential user for technical skills to determine if
| they are capable of doing the things that you are giving them
| the right to do.
| kelnos wrote:
| I think you are looking at it the wrong way. The licensor
| doesn't guarantee that the licensee can exercise the granted
| rights. But the license requires that the _distributor_ can
| guarantee that the recipient can exercise those rights.
|
| If I write up a license that says anyone distributing my
| software must give the recipient the right to drive a tank on
| their property, I can distribute it, because I am the
| copyright holder and can do whatever I want. But in practice
| that software cannot be redistributed, because those license
| terms probably cannot be fulfilled by any redistributors.
|
| If VLC wants to put something on the Unity Store that
| includes LGPL code, then their responsibility (and the Unity
| Store's responsibility, as they are now distributors as well)
| is that people downloading that Unity VLC bundle in order to
| use it in their game must be able to replace the LGPL code in
| it with modified versions. And that part may actually be
| possible, so this may be ok.
|
| But then the game developer that uses the Unity VLC bundle
| must also pass along the ability to their end users (that is,
| the people that buy and play their game, for example) to
| replace the LGPL code with modified versions. I think that's
| just not possible with the Unity Store model[0], so the terms
| of the LGPL cannot be fulfilled.
|
| If this is the case, it's not unreasonable for Unity to ban
| LGPL code in bundles, because they know that _their_
| customers (game developers) will not be able to abide by the
| terms of the license.
|
| [0] Similarly to how an end-user wouldn't be able to replace
| LGPL code in an iOS app with a modified version and then run
| that on their iPhone, at least not without paying Apple for
| the privilege, which is an added restriction that violates
| the terms of the LGPL.
| chippiewill wrote:
| I don't have experience with tinkering with typical Unity apps.
| But we have one at work and on Linux it literally has the `.so`
| files for native libraries in a standalone directory (including
| one LGPL library that we use) which you can easily replace with
| a differently compiled version if you so desired.
| tedajax wrote:
| Seems like another good argument for why the GPL and LGPL are
| actually kinda shit.
| m463 wrote:
| Thank goodness there are oracle licenses to save you. :)
| tedajax wrote:
| Yeah because MIT, BSD, etc don't exist or anything
| anthk wrote:
| Without those you would be suffering NT servers, IIS and
| ActiveX.
| Snow_Falls wrote:
| The issue is with locked down appstores, your inability to
| exercise your freedoms given by the license is caused by the
| store not the software.
| freedomben wrote:
| If that were true, then if Unity decided to ban MIT and
| Apache licensed software from the store, that would mean that
| MIT and Apache are actually kinda shit. Seems there's a
| pretty clear error in your logic.
|
| Also, your appraisal seems to be assuming that the only goal
| of the GPL/LGPL is to release software through Unity, which
| is not correct.
| naasking wrote:
| > The LGPL gives end users the right to replace the LGPLed part
| with a modified version, and users presumably cannot alter
| parts of a downloaded Unity app.
|
| You can use LGPL software on a multitenant mainframe system,
| where you don't have access to modify installed software. This
| was a well known use case in the 80s and 90s, so this doesn't
| seem appreciably different. The LGPL doesn't seem to require
| you as a software developer to ensure that the user can run the
| modified software on the same system on which the App Store
| version is run, mainly it's to make the source code available
| so they can, in principle, create a modified version that they
| can run _somewhere_.
| Steltek wrote:
| LGPL leverages copyright and is triggered under
| distribution/copying. Users of a multitenant system are not
| receiving a copy of anything. At least this is how GPL2
| worked. I don't know if 3 substantially changed that.
|
| What you're describing sounds more like the AGPL to me.
| winrid wrote:
| Steam also does not allow GPL licensed code:
| https://partner.steamgames.com/doc/sdk/uploading/distributin...
|
| Edit: if you want to link against SteamWorks
| seba_dos1 wrote:
| Games and applications distributed on Steam don't have to
| integrate with Steamworks SDK at all, and when they don't this
| licensing issue doesn't apply.
| jchw wrote:
| Note that 1. this is mostly regarding the Steamworks SDK that
| you link to; sufficient care may be taken to try to make this
| linkage to Steamworks "compliant" as noted in the article, and
| 2. this is about GPL, not LGPL. Distributing LGPL code via
| Steam may introduce some potential murkiness, but it should be
| mostly kosher since I think Steam doesn't, in and of itself,
| impede on the user's ability to exercise the rights granted by
| LGPL.
| winrid wrote:
| Right, sorry, forgot that. Edited!
| SXX wrote:
| You dont have to use Steamworks to be on Steam.
|
| There are a lot of games under GPL on Steam.
| jchw wrote:
| I find the negative reception here confusing. Seems to me they
| got removed from a marketplace, so they launched their own. They
| put the announcement into an article about the thing that
| motivated what's being announced. That is generally what you do,
| because otherwise the article would leave you with the impression
| that you have no option going forward, and a follow-up would
| reach fewer people. Just doesn't make sense.
|
| Also, I'm no Unity expert, but C# integrations generally use
| PInvoke right? It's the most dynamic of linking, there's really
| no inherent reason LGPL libs can't be used in Unity games. At
| worst, Unity should make sure you know your obligations, but I
| don't understand the necessity of a blanket ban. I'd be very
| surprised if VideoLAN, a well-respected organization that has
| been doing open source work for a very long time, had such a
| fundamental misunderstanding of the software licenses they use.
|
| Either way, a request: please stop using "clickbait" to describe
| literally anything you don't like. The article is chiefly about
| their ban, even the announcement is. By all means, critique
| whatever you want, but that's simply not what clickbait is.
| Clickbait is more like "actually we didn't get banned, But..."
| benj111 wrote:
| The sudden disjoint between story, and selling you a thing does
| seem very click baity.
|
| I think it's because they didn't stay in story mode. "So we
| decided to set up X..."
|
| To me it reads as if the company has been around for a while
| and this story has been dug/made up purely to sell a product.
| And we should expect 15 more of these.
|
| I suspect it's just bad/honest (?) Writing though.
| tankenmate wrote:
| The article said they got banned from the Unity store several
| months ago and tried for months to reconcile the issue, and
| now they have come up with a solution for their customers in
| the wake of the banning. They even included the
| correspondence from Unity in their article, so barring Unity
| coming forward with evidence of double dealing on the part of
| VideoLAN I struggle to see how "this story has been dug/made
| up purely to sell a product".
|
| Without some evidence your conclusion seems to be a hand
| wave.
| benj111 wrote:
| >"this story has been dug/made up purely to sell a product"
|
| No I said that's how it reads, Its why i suspect that
| people are saying it's click bait.
|
| My actual conclusion comes in the following paragraph.
|
| This is actually interesting from a marketing perspective.
|
| We all understand that marketing is there to sell us stuff.
| This is making us aware of a product, so it is in that
| sense at least, marketing. But then people don't like being
| 'sold to', at least they don't like noticing. This takes
| the form of 'marketing' that we don't recognise as such,
| but the disjoint puts it into an uncanny valley where it
| annoys people more than it objectively should.
|
| Is that un hand wavey enough?
| agsnu wrote:
| In Unity games on platforms like Windows, Linux, macOS sure -
| but one of the advantages of their toolkit is supporting
| porting to many platforms, like PlayStation, iOS, etc where the
| platform vendor store model's DRM & code-signing gets in the
| way of end users swapping out dynamic link libraries.
| coldacid wrote:
| Yeah but there's nothing saying that you have to support
| _every_ platform Unity runs on if you offer some package
| extending the engine.
| oefrha wrote:
| If you actually read the very long ad, you'll realize they're
| promoting all the unrelated stuff, mainly their consulting
| packages. The only thing _not_ mentioned is VLC for Unity, you
| wouldn't even know it's in the Store without clicking though.
| Nobody gets roasted for saying "by the way, you can get this
| banned product from <place> now", this is some next level shit
| that makes people question your integrity and your one-sided
| story.
|
| Edit: Apparently some people can't understand what I mean by
| "the very long ad". It's everything starting from "Introducing
| the Videolabs Store", not the whole article.
| smaudet wrote:
| To be completely fair, their plug-in is still freely
| available. After being kicked off by unfair and unreasonable
| (uncompetitive?) practices, it's not unreasonable to say "hey
| they suck so we are doing our own thing over here". If
| someone robs you it's not unethical to set up shop elsewhere.
|
| Asking for money for support is entirely reasonable as well.
| martz wrote:
| post author here. Yes, basically all of what you said. I've
| edited the post.
| theseagin wrote:
| Not all hero's wear capes. You sir are definitely one.
| master-lincoln wrote:
| For expressing their opinion and providing reasoning? Seems a
| bit inflationary to me to use the word hero here
| froh wrote:
| no, for changing the mind of the original author of the
| posted article.
| johnnyanmac wrote:
| > Seems to me they got removed from a marketplace, so they
| launched their own.
|
| not only removed, but removed with no hope of reconciliation
| (if the author is to be believed). They offered to remove all
| LGPL code to comply and were refused. Their entire publisher
| account was banned over what I assume is one infraction. They
| made it pretty clear that Unity just didn't want VLC on their
| store.
| jmull wrote:
| We're hearing one side of the story here, so who knows, but
| looking at it from Unity's perspective...
|
| Unity doesn't want to have be the "cops" and "prosecutors"
| who have to go around to find, investigate, adjudicate and
| enforce violations in the store agreements. They want
| partners who, having agreed to the store terms, will make
| reasonable efforts to adhere to them.
|
| E.g., Unity may have come to the conclusion that VLC violated
| the terms of the store agreement not by simple mistake or a
| reasonable different interpretation of the agreement, but on-
| purpose or through negligence. In that case, the reasonable
| thing to do is to simply stop doing business with VLC (if
| it's not too costly to do so), because of the relatively high
| likelihood it will happen again.
|
| Don't forget that Unity could be sued for violating the terms
| of LGPL'd software. If they "have received a report" of an
| LGPL violation, they have to take it seriously. Any future
| lawsuit would likely be more successful if they had
| previously received a report of a violation and did not
| resolve it..
| dangus wrote:
| > ...if they had previously received a report of a
| violation and did not resolve it..
|
| "Resolve it" would include working with the offender to
| remove the LGPL violation. They could easily document the
| process and demonstrate a good-faith effort to comply.
|
| Sure, Unity is well within their rights to kick Videolan
| off their store. It's the cheapest way to comply: no need
| to collaborate with store vendors and put any hours into
| that sort of thing.
|
| But that's all it is, a cheap way to comply. It's the
| laziest form of compliance at the expense of their own
| customer experience.
| smaudet wrote:
| Except that's not what happened at all, at least per the
| article they use LGPL and have LGPL code all over their
| store, and refuse to work with the OP at all over the
| issue.
|
| Unity are absolutely to blaim here, this is indefensible.
| jmull wrote:
| > Except that's not what happened at all
|
| You're not disputing anything I wrote though.
|
| If a license violation is reported and Unity ignores it
| their legal risk is higher than for violations no one has
| reported. The report forces their hand, to a degree.
|
| From the post: "Enforcement is seemingly totally random,
| unless you get reported by someone, apparently." ...
| which is another way of acknowledging enforcement isn't
| random. The report matters. That's what moves the
| responsibility for adhering to the license from the asset
| provider (VLC in this case) to Unity.
|
| BTW, "other people are doing it too" isn't a great excuse
| for violating license terms. If that was OK, then
| licenses would be generally be almost meaningless.
|
| Regarding Unity's direct usage of LGPL code, that's on
| them. They need to make sure to honor the LGPL license.
| Nobody made the claim they weren't, so I'm not sure it's
| relevant.
|
| Here's another bit from the post that I thought was
| telling: "After months of slow back-and-forth over email
| trying to find a compromise..." What compromise? If you
| find out you're violating an open source license you stop
| as promptly as you reasonably can. It's not a matter of
| negotiating with Unity -- that's a separate agreement. It
| sounds like they eventually came to the right conclusion
| re the LGPL components, but why was honoring the LGPL
| license even in doubt? It makes me think they aren't
| really sincere about open source licenses (and maybe
| other licenses or any kind of agreement). Note, this
| point is entirely independent of Unity and whether or not
| they are screwing VLC. When distributing binaries built
| with LGPL code, they have a responsibility to honor the
| license, but only seemed willing to do so reluctantly and
| belatedly, after pressure from a business partner.
| throwaway2037 wrote:
| This whole system of arbitrary enforcement on an "app store"
| seems weird to me. Real question: Would our economies be
| better off with stronger regulation around app stores? In the
| last one year, I am leaning more towards yes. My thinking:
| Many small companies are completely beholden to a single app
| store. If any small thing goes wrong, the business get the
| middle finder and suffers greatly. It seems like a David and
| Goliath situation, but Goliath drives a Leopard 2 tank and
| David still has a sling shot.
|
| Idea: What if there were some minimum, legal requirements for
| app stores? Example: If the app store owner enforces a rule,
| it must be enforced equally on all apps. (Obviously, that did
| not happen in this case.) If complaining / escalating due to
| unfair treatment is not remedied, there is a neutral gov't
| board that can make a ruling. This is not unlike labour union
| relations in countries with strong labour laws.
| djbusby wrote:
| Like disputing with Amazon. Step one: pay $2000 for
| arbitration.
|
| It's out of reach for many Davids
| torginus wrote:
| To be fair, since the LGPL part of VLC is _FFMpeg_ there 's
| zero chance that they can produce a working product without
| LGPL code.
| ziddoap wrote:
| > _Either way, a request: please stop using "clickbait" to
| describe literally anything you don't like._
|
| Preach on. This is one of the most annoying things, to me at
| least, here. If there is a post with more than 10 comments,
| there's a very good chance one of those comments contains
| "clickbait".
|
| The word has lost all meaning to me at this point.
| PH95VuimJjqBqy wrote:
| I disagree in general (although I agree this article isn't
| clickbait).
|
| the internet runs on clickbait and HN's insistence on
| reflecting the title of the content itself means a lot of
| things that are posted are legitimately clickbait.
|
| Just this morning I rolled my eyes when I saw an article
| titled "Airbus shatters record for jet orders as demand
| soars" (https://news.ycombinator.com/item?id=38967262).
|
| I didn't even bother clicking on it.
|
| people are getting oversensitive, but not without good
| reason.
| ziddoap wrote:
| In your opinion, what makes your example article title
| clickbait? Is it using the word "shatters" as opposed to
| "more than doubles"?
|
| Maybe I'm just stuck on an old definition or something, but
| in my mind, clickbait refers to a headline that is
| _purposfully dishonest_ about the content of the article.
| Having an eye-catching title doesn 't mean it's clickbait
| if the article delivers on what the title says.
|
| I guess I would also classify any title that doesn't give
| _any_ representation of the article content as clickbait as
| well. "Airbus shatters records", as an example, wouldn't
| give any indication of what records were shattered, thus
| baiting clicks.
|
| But, maybe the word has evolved to refer to any non-boring
| title and I just haven't caught up to the times.
| PH95VuimJjqBqy wrote:
| because of the adjective shatters.
|
| "doubles" is accurate but not as strong in the mind of
| the reader.
|
| it's like seeing an entry in youtube titled "person x
| DESTROYS person y" and it turns out it's just your
| normal, everyday, point/counter-point discussion.
|
| It's meant to increase the odds that you click, and
| that's literally what clickbait is.
| pvg wrote:
| _I find the negative reception here confusing. [...] Either
| way, a request: please stop using "clickbait"_
|
| You're better off directing this stuff to whatever negative
| reaction or word usage you're referring to otherwise you get a
| subthread of meta/ants. Or for even less effort required, just
| skip it. Almost all comments are greatly improved by meta-
| elision.
| moss2 wrote:
| Wouldn't be surprised if Unity is developing their own multimedia
| engine they want to sell. Shitty practices like this is what
| makes me want to get into politics.
| yard2010 wrote:
| Ikr if you can't beat them join them and hf
| UberFly wrote:
| This was my first thought. They can then sell some poorly-
| executed knockoff, ignoring that a partnership with actual
| experts would have been the best for their customers.
| jbk wrote:
| (Disclaimer: President of VideoLAN here)
|
| Just a few remarks: VLC-Unity plugin is fully open source, and
| anyone skilled enough can build it themself.
|
| We've tried for months to discuss with Unity and it was a
| nightmare. We've had discussions for years with Apple AppStore,
| Google Play store, and Windows Stores (including Windows Mobile +
| UWP). It's always challenging, but Unity was a headache an order
| of magnitude bigger: no answers, 3 different answers
| contradicting each other, and plain bad faith.
|
| De facto, they use LGPL and open source to build their platform,
| but we're not allowed to have open source on the store? Not even
| LGPL with a layer of a different license? Why us? Why not the
| other people doing it?
|
| Very frustrating.
|
| So, yes, because some people need to buy support or licenses,
| even if everything is open source (don't want to build
| themselves, purchase department that needs a support contract,
| etc...), they need to have a small store. This is different from
| what we see usually, but there is a need, so this is a small
| store for that.
|
| For most of HN users, you should just build it yourself. You
| should be skilled enough for that :)
| vertis wrote:
| Ah, when I was using Unity I would often buy items I could have
| built myself even though they were open source, for several
| reasons:
|
| - only so many hours in the day - it's nice to pay people for
| things they work on - stable release version
|
| I'm thankfully not using Unity any more. Watched the recent
| installs cluster** from a bemused distance.
| yard2010 wrote:
| I would wage against it. It's as shitty as Blockbuster. No
| reason they won't end up selling for peanuts
| gumby wrote:
| When I originally wrote the LGPL (v1, back around 1991) we could
| not imagine anything like an App Store or signed binaries.
| Dynamic linking provided an easy way for users to upgrade the
| library code.
|
| Since the user doesn't have the freedom to update the libs on ios
| etc I don't see how you could deploy LGPL code on those
| platforms; since one of the points of using unity is its cross-
| platform support, that suggests you'd have to find another
| library unless you were only deploying on real OSes.
|
| But is that Unity's problem?
| qwertox wrote:
| > But is that Unity's problem?
|
| Apparently not. "Unity itself, both the Editor and the runtime
| (which means your shipped game) is already using LGPL
| dependencies"
| tonmoy wrote:
| So I could be missing something, but the editor itself is not
| getting shipped to iOS devices, only the resulting binaries
| are.
| Vinnl wrote:
| That sounds like the "and the runtime (which means your
| shipped game)" part?
| doctorpangloss wrote:
| Nobody in this thread has firmly pointed to LGPL code
| being linked or used in the iOS runtime in a Unity 2021
| or later built game. Having not looked at this myself, I
| can't say either way, but it is almost certainly wrong to
| say that the runtime contains otherwise LGPL code that
| was not expressly licensed or permitted for the purpose
| by its authors.
| voxic11 wrote:
| The resulting binaries depend on the unity runtime which
| itself depends on these LGPL components.
| OmarAssadi wrote:
| Tangent, but out of curiosity, what was the more important goal
| in your mind/whoever else was involved? The ability to relink
| with newer/patched libraries, or simply the ability to
| inspect/modify the LGPLed code?
|
| I have a love-hate with the ultra-permissive licenses; on the
| one-hand, philosophically, I think I prefer the idea of
| trusting the recipient to just not be an asshole, but at the
| same time, I recognize [1] that corporations [which tend to
| prefer permissive licenses] don't always have the best
| interests of everyone in mind.
|
| Even in ideal cases, like how the LLVM community tends to at
| least see LLVM most of the LLVM forks patches--even if they are
| not accepted--simply because it's effort to maintain a
| downstream fork of something so fast moving, community-wise, I
| feel like Apache 2.0 and friends end up very different, perhaps
| corporate, in a way that I don't love.
|
| For example, I used to wonder how GCC still had so much backing
| since LLVM is generally easier to work with, from my
| experience, no wild autotools insanity, etc. But after doing
| the full UEFI -> modern Linux + GCC/LLVM bootstrap, I really
| appreciate the care taken to avoid constant churn to minimum
| C++ versions, support for obscure platforms, etc; it feels like
| LLVM sort of disregards anything that doesn't make a ton of
| visible economic sense [2], which makes the bootstrapping
| process so much more awful by limiting the number of potential
| platforms plus requiring even more steps than GCC, which is
| brutal on its own.
|
| Anyway, I guess I was wondering, if you were doing it all over
| again, would something like the MPL 2.0 perhaps have fit the
| bill better? One benefit of the LGPL, to me, of course, is that
| you should, _in theory_ , be able to link against a different
| copy. But at the same time, I guess I am more concerned about
| the ability to allow useful libraries to remain in the hands of
| the users to modify than I am about them to be able to fix a
| bug whatever random proprietary program--worst case, if it's
| something entirely unmaintained, I can often binary patch
| whatever bug or similar.
|
| I feel like the LGPL, while nice in theory, probably causes
| more harm [for me] relative to the MPL simply because people
| are [unnecessarily] afraid of potential implications with
| static linking, or perhaps cannot be bothered distributing
| individual object files alongside the static binary to allow
| relinking. So, we end up with people choosing non-copyleft
| alternatives or reinventing the wheel as proprietary software.
|
| I have similar feelings with the less-selective GPL; we've
| ended up with the horrible situation of people distributing
| images that pull the entirety of the Ubuntu userspace just to
| emulate static binaries via containers.
|
| Anyway, tangent over. Also, I wish there was a well-accepted
| CDDL/MPL 2.0-style license with a network distribution clause;
| I think I've become a fan of file-based copyleft as a good
| middleground, but it's annoying that there isn't a popular
| file-based copyleft license that takes into account AWS and
| similar.
|
| EDIT: Also, I guess similar to what you already touched on RE:
| iOS. I feel like GPL 3.0 was probably a mistake. Presumably
| good intentions, but I feel like the hand was overplayed; it
| simultaneously went too far for companies like Apple to touch
| it, so we ended up with ancient Bash and GNU Make with gradual
| replacement of anything GPL, and yet also simultaneously not
| far enough to deal with cloud services, containerized RPC-style
| not-technically-linking-but-basically-linking distribution,
| etc.
|
| [1]: Personal opinion -- I know this is a VC website at the end
| of the day and people will disagree with me. I don't really
| care to argue about it.
|
| [2]: Not meant to be an attack against LLVM. And I know there
| are loads of independent developers and researchers working on
| it too. I hope my feelings don't get totally misunderstood.
| zigzag312 wrote:
| To me, CDDL/MPL 2.0-style licenses are much more sane than
| GPL based ones.
|
| The definition of what is a derivative work is IMHO
| overreaching in GPL based licenses.
| gumby wrote:
| > The definition of what is a derivative work is IMHO
| overreaching in GPL based licenses.
|
| GPL doesn't use the word "derive" and specifies modified
| work in a way that is consistent with the customary legal
| definition.
|
| People twist things around because they want to use GPLed
| code without "paying" for it, but really at the end of the
| day it's just an ordinary license agreement but instead of
| paying cash to use it you agree to give users the freedom
| to modify and/or redistribute the code.
|
| Just like any other licensed code you can agree to the
| terms and use the code or disagree with the terms and use
| something else.
| zigzag312 wrote:
| It doesn't really matter where exactly it is defined.
| There's effective definition of derivative works in place
| for GPL, even though it's definition is inherited.
|
| > People twist things around because they want to use
| GPLed code without "paying" for it, but really at the end
| of the day it's just an ordinary license agreement but
| instead of paying cash to use it you agree to give users
| the freedom to modify and/or redistribute the code.
|
| You mean, instead of paying cash to use it, you pay with
| your property (your code). An old school barter exchange.
|
| Source of confusion probably comes from overuse of the
| word "free" by people promoting GPL, which is like you
| said, just an ordinary license agreement.
| aleph_minus_one wrote:
| > You mean, instead of paying cash to use it, you pay
| with your property (your code). An old school barter
| exchange.
|
| It's not that simple. If it was just about "my" code,
| this would indeed your claimed barter exchange. But
| often, say in industry, the code that you develop is
| combined with a lot of third party code and libraries for
| which you simply do not have the permission to put them
| under GPL.
| kelnos wrote:
| That's fine, and isn't the responsibility of the author
| of the GPL code you want to use. If you can comply with
| the terms of the license, great, you can use it. If you
| can't, you need to find something else whose license
| terms you can comply with. And you might have to pay
| money for it, but that's life.
| teddyh wrote:
| IIUC, GPL based licensed do _not_ define what what
| derivative work it, but leaves it to the law.
| simiones wrote:
| The GPL can't really overwrite the legal definition of
| derivative work, even if it wanted to. Of course, there is
| little case law actually going into the weeds, so it's hard
| to say for sure. However, the GPL's definition seems pretty
| reasonable to me as to what would constitute a derived work
| (anything linking with the GPL work OR anything passing
| very very complex structures between itself and the GPL
| work).
|
| In fact, I suspect that a legal definition of exactly what
| constitutes a derived work of a program may be more broad
| than the GPL's definition. For example, it's plausible to
| me that a program which calls `sh` as a fundamental part of
| its functioning could be found to represent a derivative
| work of `sh` per copyright laws.
| zigzag312 wrote:
| Hmm, maybe didn't use the correct term when I said
| "derivative work".
|
| What term defines the scope to which copyleft applies to?
| simiones wrote:
| I think derived work or derivative work are the right
| terms. However, "copyleft" is not a legal term, and it is
| copyright law (and associated jurisprudence) that defines
| what constitutes a derived work of some original.
| Licenses then control what the copyright holder allows
| you to do with their works or derivatives.
|
| So, only copyright law itself can say whether, for
| example, this comment I'm making is a derived work of
| your own comment, or if it is an original work of my own.
| If it is a derived work of your comment, then you are the
| copyright holder for this comment I'm making and you can
| choose to write a license that allows me to distribute it
| or nor or whatever else. If it is _not_ a derived work,
| then I am the copyright holder, and I don 't require any
| license from you to distribute this comment.
|
| So, if copyright law were to say "a computer program A is
| a derived work of program B if and only if it is produced
| from the same source code of A or textual modifications
| of the code of A" (very implausible, but just for the
| sake of argument), then there would be no difference
| between the GPL and the LGPL, and you could freely link
| to a GPL program and distribute the result under a
| proprietary license (you'd still have to distribute the
| source code of the original GPL program, of course).
| zigzag312 wrote:
| So, derivative work term in copyright law defines the
| scope only as binary all or nothing? It's always a whole
| product that is considered derived, never just part of a
| product.
|
| And license itself can then limit the scope of copyleft,
| so that it applies it to only a specific part of a work.
| simiones wrote:
| Note that I am not by any means a lawyer, so please don't
| take my understanding as authoritative.
|
| My understanding is that "a work" and "a product" are
| different things. If I sell you a bundle of three books,
| the bundle is a product, but each book is an individual
| work and caries its own copyright. Even a single book may
| contain 5 short stories, each with a different copyright
| holder and license.
|
| Similarly, I can sell you one CD that contains three
| different works with different licenses. Now, it is true
| that the GPL license does seem to say that you can't
| distribute a modified GPL work on the same CD as a non-
| GPL work, which would not fall under copyright law, it
| would just be an arbitrary requirement of the license
| that you have to accept if you want to be able to
| distribute the GPL work at all (by default, you're not
| allowed to distribute copyrighted work at all - it's only
| the terms of the license that allow you to).
|
| However, the derived work problem comes more into
| question when you write a program that only works if it
| is linked with, say, glibc. The question becomes: is your
| program a separate work from glibc, or is it a derived
| work of glibc? If it is a derived work, then the GNU
| project is the copyright holder of the program you wrote,
| and you're not allowed to distribute it at all unless you
| get some license from them. If it is NOT a derived work,
| then you are at least free to distribute your program
| however you want, and tell your customers "just download
| glibc from gnu.org, put it at this path, then start my
| program", and the glibc license could do nothing to stop
| you since it doesn't apply in any way.
|
| An analogy with books would be you writing a book that's
| meant as a sequel to Harry Potter. It is quite well
| established that even if your book is fully original, if
| it uses characters from Harry Potter by name, or
| locations or other key concepts, then your book is a
| derived work of the Harry Potter franchise and you're not
| allowed to sell it even if you're not directly using any
| piece of the originals.
|
| Either way though, if you're creating a derived work, the
| license of the original can allow you to distribute your
| derived work under any terms they want. A license could
| say "you can distribute derived works for free on
| Wednesdays, but you have to pay a royalty if it's any
| other day of the week". Or, more interestingly, the
| license could say "you can distribute derived works
| without any conditions if they only access our original
| work through DLOPEN, but if they are accessing it through
| static linking, you must release the code and build
| instructions for your derived work" - this is what the
| LGPL does.
| kelnos wrote:
| > _Now, it is true that the GPL license does seem to say
| that you can 't distribute a modified GPL work on the
| same CD as a non-GPL work_
|
| No it's not. The GPL specifically says that mere
| aggregation of a GPL-licensed work with another work
| licensed under another license does not create any sort
| of GPL obligation on the other work:
|
| > _A compilation of a covered work with other separate
| and independent works, which are not by their nature
| extensions of the covered work, and which are not
| combined with it such as to form a larger program, in or
| on a volume of a storage or distribution medium, is
| called an "aggregate" if the compilation and its
| resulting copyright are not used to limit the access or
| legal rights of the compilation 's users beyond what the
| individual works permit. Inclusion of a covered work in
| an aggregate does not cause this License to apply to the
| other parts of the aggregate._
| tsimionescu wrote:
| Here I am deferring to my company's lawyer. I believe
| they are interpreting (very likely incorrectly, but then
| they are a lawyer and I am not) this part:
|
| > You must license the entire work, as a whole, under
| this License to anyone who comes into possession of a
| copy. This License will therefore apply, along with any
| applicable section 7 additional terms, to the whole of
| the work, and all its parts, regardless of how they are
| packaged.
| kelnos wrote:
| > _If it is a derived work of your comment, then you are
| the copyright holder for this comment_
|
| Is that correct? I am also not a lawyer, but this seems
| wrong to me.
|
| If I make something that is a derived work of some other
| copyrighted work, my understanding is that I still own
| the copyright on the parts of the final work that I made
| (assuming what I made meets the thresholds for being
| copyrightable). But I am not permitted to distribute that
| work unless I receive a license to do so from the owner
| of the work I've derived from.
|
| My understanding seems to dovetail with how the GPL
| works. If I write a program that links to a GPL library,
| and that does indeed cause my program to become a derived
| work of the GPL library, I still own the copyright to my
| program. In order to distribute my program, I have to
| abide by the terms of the GPL. But even if I were to
| violate the terms of the GPL (thus terminating my rights
| under the GPL), I still would not lose my copyright
| interest in the program I wrote, only my right to
| distribute it.
| tsimionescu wrote:
| Looking this up a little bit more, I think it's more
| complicated than I was saying but also than you're
| saying.
|
| For the "normal" cases, you're right: you can have
| copyright on the original parts of a derived work. You
| are fully right though that the original work's author
| does not in any circumstance get the copyright for the
| derived work. That was a confusion on my part.
|
| > But even if I were to violate the terms of the GPL
| (thus terminating my rights under the GPL), I still would
| not lose my copyright interest in the program I wrote,
| only my right to distribute it.
|
| As far as I understand though, this is not true. If you
| were not authorized to use the original work, then even
| the original parts of your work are in fact not protected
| by copyright at all. So, if, say, I take a Spiderman
| comic and add an extra page of fanart at the end, without
| any authorization from Marvel/Disney, then my extra page
| of fanart is not protected by copyright at all, and
| anyone is free to copy it (unless it also infringes on
| Marvel/Disney's copyright of course) [0]:
|
| > Only the owner of copyright in a work has the right to
| prepare, or to authorize someone else to create, an
| adaptation of that work. The owner of a copyright is
| generally the author or someone who has obtained the
| exclusive rights from the author. In any case where a
| copyrighted work is used without the permission of the
| copyright owner, copyright protection will not extend to
| any part of the work in which such material has been used
| unlawfully. The unauthorized adaptation of a work may
| constitute copyright infringement.
|
| [0] https://copyright.gov/circs/circ14.pdf
| gumby wrote:
| > Tangent, but out of curiosity, what was the more important
| goal in your mind/whoever else was involved? The ability to
| relink with newer/patched libraries, or simply the ability to
| inspect/modify the LGPLed code?
|
| The freedom of the user to modify the library and use it was
| the most important part. It's a fundamental "right to
| repair".
|
| FWIW the people involved were just me, plus John Gilmore who
| said "why not explicitly make dynamic linking automatically
| qualify?" which was obviously a good idea, and RMS who was
| bitterly opposed.
| toyg wrote:
| I mean, it's like telling the pope that Jesus is the son of
| god only on Mondays and Tuesdays, eh...
| NohatCoder wrote:
| I wonder how many times that has happened? Specifically
| someone intentionally modifying the behaviour of a closed
| source program by changing an LGPL library that it depends
| on.
| freedomben wrote:
| I personally know of that happening twice. In both cases
| it was used to patch a bug in the super old Qt version
| that was being shipped.
|
| I'm sure it doesn't happen often, but IMHO that doesn't
| really matter. It's preserving the freedom to do it that
| is important. I rarely use my right to free speech (that
| is, saying something that somebody in power would find
| offensive and want to jail me for), but it's a right I
| would fight to the bitter end to preserve.
| captainmuon wrote:
| I've never understood the problem with (L)GPL code on iOS
| devices. Sure, users don't have the possibility to replace the
| code on that platform. But the restriction is not imposed by
| the people distributing the code, but by external circumstances
| (Apple).
|
| I can distribute LGPL licensed code to people no problem even
| if they are then, additionally, forbidden to actually excercise
| their freedoms by laws, think for example about radio code. I
| might have to get a special permission to run the code if I
| make changes and compile it, but that's no concern of the
| person licensing their source code to me.
|
| Same if, say, the code runs on a box in an inaccessible space,
| and in order to install their own binaries somebody would have
| to press a button that they can't reach. That's not a GPL
| violation.
|
| If I have the OK from Tim Cook and all the secret signing keys,
| I can compile and run anything I want on my iOS device. And
| even without that, if somebody provides all the object files of
| non-LGPL code and build instructions, I can replace the LGPL
| code and run my own version outside of the app store. Often
| when people ban (L)GPL code, its just a pretext, because they
| don't want to deal with the complexities or for other reasons.
|
| Edit: I've been thinking about LGPL 2.1. I think LGPL 3 does
| explicitly forbid the above mentioned situations?
|
| (And of course this is just my reading as an interested
| layperson, you're the expert obviously :-))
| ffgjgf1 wrote:
| > I've never understood the problem with (L)GPL code on iOS
| devices
|
| AFAIK Apple just doesn't allow apps which don't that on the
| app store regardless of how the developer would chose to
| interpret the license
| wahnfrieden wrote:
| that's outdated info
| BizarroLand wrote:
| Your face is on backwards if you think it's acceptable to
| tell someone that their information is outdated without
| also providing the new and up to date information.
| beeboobaa wrote:
| It's Apple's App Store. Being vague and non committal is
| how they roll.
| mort96 wrote:
| Let's imagine I'm making MortPlayer, a video player for iOS
| which uses a version of the VLC libraries which are licensed
| under LGPL 2.1 (since that's what you're focusing on). Let's
| say I want MortPlayer to be closed source.
|
| In other words, VLC owns the libraries, and I want to license
| them under the LGPL 2.1.
|
| The LGPL 2.1 says: 6. As an exception to
| the Sections above, you may also combine or link a "work that
| uses the Library" with the Library to produce a work
| containing portions of the Library, and distribute
| that work under terms of your choice, provided that the
| terms permit modification of the work for the customer's own
| use and reverse engineering for debugging such
| modifications.
|
| Okay, so I must distribute MortPlayer under terms which
| permit modification and reverse engineering. I can do that.
| Maybe Apple's terms conflict, but let's assume that's not an
| issue, let's read on. You must give
| prominent notice with each copy of the work that the Library
| is used in it and that the Library and its use are
| covered by this License. You must supply a copy of
| this License. If the work during execution displays copyright
| notices, you must include the copyright notice for
| the Library among them, as well as a reference
| directing the user to the copy of this License.
|
| Okay, no problem. Also, you must do one of
| these things:
|
| Oh boy. a) Accompany the work with the
| complete corresponding machine-readable source code
| for the Library including whatever changes were used in the
| work (which must be distributed under Sections 1 and
| 2 above); and, if the work is an executable linked
| with the Library, with the complete machine-readable "work
| that uses the Library", as object code and/or source
| code, so that the user can modify the Library and then
| relink to produce a modified executable containing the
| modified Library. (It is understood that the user who
| changes the contents of definitions files in the
| Library will not necessarily be able to recompile the
| application to use the modified definitions.)
|
| Okay. I can accompany the work (MortPlayer) with the source
| code for VLC's libraries, no problem. MortPlayer is executed
| and linked with VLC's libraries, so I need to 'accompany the
| work with ... the complete machine-readable "work that uses
| the Library", as object code and/or source code, so that the
| user can modify the Library and then relink to produce a
| modified executable containing the modified Library".
|
| I think that's doable with app stores? I can certainly
| distribute a zip file with the object files for MortPlayer so
| that the user can link them against their own version of VLC.
| The user wouldn't be able to then run the recompiled
| application, on their device, but that's not specified in the
| terms...
|
| Honestly I'm a bit surprised, I fully expected to find that
| this section a) included wording which requires the user to
| be able to run the resulting linked application, which Apple
| forbids (asterisk), and then go through b) and conclude that
| iOS doesn't have a "suitable shared library mechanism" due to
| its restrictions etc. But I'm instead forced to conclude that
| you're probably right, at least by the letter of the license.
|
| I read the corresponding parts of LGPL 3 as well, and I can't
| find anything which requires the re-linked application to be
| immediately executable on the user's machine there either.
|
| I think my conclusion is that LGPL, both 2.1 and 3.0, is
| fully compatible with app stores so long as you distribute
| your application as object code which can be linked against
| the LGPL licensed libraries? I would be very interested to
| hear from someone with opposing views about why I may be
| wrong. I, as they say, ANAL.
| naasking wrote:
| It should be compatible with app stores. How would the
| inability to swap out the VLC library be any different from
| a program that you can't change because it's on a system
| managed by a sysadmin? Of course you, as a user, can run
| LGPL programs on mainframes or other third-party managed
| systems, this was a well known use case when the LGPL was
| written.
| actionfromafar wrote:
| It's all about the distribution of copyrighted material.
| The "user" then is the admin which received the program.
| The other used without admin, is just using some remote
| service. (With telnet/ssh. No distribution of copyrighted
| material is going on there, just input/output from a
| remote service, like a web site running LGPL code.)
| hedora wrote:
| Are these new changes with LGPL 2.1? I don't remember it
| containing the modification and relinking restrictions in
| the past. It kind of defeats the purpose of the LGPL IMO.
|
| As an aside, it really bugs me that the GPL morphed into
| this thing that gives developers the freedom to run privacy
| violating and user-abusing cloud services, but doesn't
| allow manufacturers to ship the same stuff on physical (and
| perhaps offline) hardware the end users have physical
| control over.
|
| When the GPL 3 added the anti-TiVo clause, it really should
| have also added AGPL's anti-google clauses at the same
| time.
|
| Anyway, I guess the above restriction means I won't be
| using LGPL for stuff I write at work, even though most of
| what we do gets open sourced anyway.
| mort96 wrote:
| Huh? The whole point of the LGPL is to say, "you can use
| the LGPL'd code in your closed-source product, but the
| user must be able to replace the LGPL part of your
| product with their own version". The way to achieve that
| is to either use some kind of dynamic linking where the
| user can provide their own .so/.dll/.dylib of the LGPL'd
| library, or to provide the object files so that the user
| can statically re-link the application with their own
| version of the LGPL'd library.
|
| This is different from GPL, since you can't use GPL'd
| code in your closed-source product at all, not even if
| you let the user replace the GPL'd portion with their own
| version.
|
| What purpose of the LGPL is defeated?
| hedora wrote:
| I thought the purpose of the LGPL was that it could be
| used for libraries without tainting the stuff the library
| is linked against with viral GPL restrictions.
|
| Concretely, using gcc with default settings will bring in
| glibc and compiler intrinsic code snippets which were
| both LGPL last time I checked. If I use GCC to compile
| and statically link closed source code that I have a
| redistribution without modification license for, then I
| can't redistribute my binary without violating my license
| for the closed source code.
|
| Ouch! MUSL + clang it is, I guess. (I value my users'
| right to own and operate computers even higher than their
| right to recompile code, so I'd rather not restrict my
| lgpl tainted binaries so they can only run in the cloud).
| rescbr wrote:
| IIRC, GCC specifically uses GPL + runtime license
| exception to avoid this scenario
| mort96 wrote:
| glibc's LGPL is generally no problem because you honor
| that simply by dynamically linking against it. Normal
| desktop Linux distributions do have a "suitable shared
| library mechanism" as the LGPL calls it, so if your
| binary is dynamically linked against glibc, your users
| are free to link against the user's modified libc. The
| "Distribute object files to allow re-linking" thing only
| becomes relevant if you don't use a "suitable shared
| library mechanism" to dynamcially link against the LGPL-
| licensed library.
|
| However, if you do choose to statically link against
| glibc (which is highly discouraged, for technical
| reasons) then yeah, you have to give your users access to
| object files or some other mechanism to statically link
| against a different version of glibc than the one in the
| executables you ship. And yeah, this might potentially be
| incompatible with the licenses for certain proprietary
| libraries, which simply means that you can't statically
| link against those binaries _and_ LGPL-licensed libraries
| at the same time.
|
| The stuff in GCC which gets includes into your binary
| (such as crt0.o, and whatever code it generates) is
| except from the GPL.
|
| I have no idea what you're talking about wrt restricting
| your users to only run your binaries in the cloud.
| hedora wrote:
| If you sell a device with Linux and a proprietary blob on
| it, then you're arguably doing the linking, not the user.
| On top of that, if you enable link time optimization,
| then you have to link at build.
|
| All of this would be allowed if you put the same device
| in a data center, and then had the user connect to it
| remotely.
| gorkish wrote:
| > What purpose of the LGPL is defeated?
|
| The purpose of /which/ LGPL? And that's the thing. After
| GPL demonstrated that it had teeth and got some case law
| underneath it, the "family" of derivatives exploded, each
| one of them identifying as "open source" but each with
| their own additions, removals, modifications or other
| opinions on what "freedoms" they convey (mostly
| removals).
|
| There are those of us out here who believe that the core
| purpose of all of these licenses were defeated a long
| time ago when all of this legal swizzling first began. I
| personally hate GPLv3, AGPL, LGPLv3, etc. with a fiery
| burning passion; thank god we were able to see some
| transformative projects emerge under actually free
| licenses before everything got ruined.
| mort96 wrote:
| > The purpose of /which/ LGPL
|
| Either 2.1 or 3.0 I guess, the difference between the
| versions isn't that relevant to hedora's question.
|
| The GPL exists to protect users against companies which
| develop proprietary software. If you prioritize the
| freedom of companies to restrict users over the freedom
| of those users, it makes sense that you'd dislike the GPL
| style licenses.
| freedomben wrote:
| > _I personally hate GPLv3, AGPL, LGPLv3, etc. with a
| fiery burning passion; thank god we were able to see some
| transformative projects emerge under actually free
| licenses before everything got ruined._
|
| Why do you hate them so much? Is it strictly as a
| developer, or as a user?
|
| As a developer I've certainly felt constrained and
| annoyed by them at times, and I'm very glad there are
| alternative open source licenses available, but as a user
| I can't imagine a scenario where you would hate them.
| After all, the freedom they guarantee is to _the user_ ,
| not the developer.
|
| Even as a developer though, the family has it's place. I
| don't think Linux would be a thing had it had a more
| "permissive" license. That GPL is what forces the big
| corps to contribute their improvements back. If not for
| the GPL, I think it would be in a position similar to
| that of BSD, and the majority of users would have no
| choice but to use a proprietary OS
| bombcar wrote:
| Notice the lack of "GPL" in that list, and I'm partially
| in agreement.
|
| The GPL is amazing and wonderful, but the various
| "attachments" of the GPL are more weaponized (and to the
| detriment of users!) than the GPL ever was.
|
| I'm glad the kernel stuck with GPLv2, and I wish other
| things had, too. A GPLv3 Linux Kernel would likely have
| helped a BSD tremendously, though but I think having
| everyone work on the same kernel without reservations has
| been an unmitigated good.
| singpolyma3 wrote:
| GPLv3 isn't enough different from GPLv2 to matter in
| practice, usually. It's mostly clarifications like the
| cure provision.
| jlokier wrote:
| It's different enough that Apple thinks it's only safe
| for them to ship GPLv2 software on MacOS devices, not
| GPLv3.
|
| This might have something to do with the way they sign
| shipped versions and use TPM security to verify what's
| run, even though you can manually disable some of this if
| you want.
|
| So all GPL the software shipped on MacOS devices is stuck
| at the last version which used GPLv2, and they rewrote
| Samba which they had previously shipped, whose last GPLv2
| version is too out of date to keep using.
| mort96 wrote:
| Wait are you only angry at the AGPL? Or what are you
| calling attachments to the GPL?
|
| LGPL is a relaxation of the GPL, by the way.
| kmeisthax wrote:
| > When the GPL 3 added the anti-TiVo clause, it really
| should have also added AGPL's anti-google clauses at the
| same time.
|
| They tried that, everyone balked. You know how Linus
| Torvalds rejected GPLv3 for Linux specifically because
| anti-TiVo[0] would be "changing the deal"? Imagine that
| times a thousand.
|
| Furthermore, AGPL is only an anti-Google license
| specifically because Google is as internally afraid of it
| as Microsoft is of GPL. You can defeat the Affero clause
| by putting the software behind a proxy, for example.
| Furthermore, the Affero clause is only appropriate for
| web applications - ideally ones in dynamic languages that
| execute from source that remains on disk. Slapping it on
| _all GPL software_ would be really, really dangerous. I
| 've heard of people using AGPL on Ethernet PHYs - how the
| fuck do you offer source code to every packet that
| crosses an Ethernet switch?
|
| If you really want a license clause that would absolutely
| decimate any corporate freeloading behavior, you want
| OpenWatcom's anti-private-forks clause[1]. It does
| everything AGPL tries to do, with fewer legal loopholes.
| But good luck getting that past RMS. The problem with
| supra-GPL copylefts is that anything that is legally
| watertight to a corporation is also going to impinge on a
| lot of freedoms we enjoy. Remember: the whole point of
| the GPL is to _reject_ copyright, and that specifically
| means lots of corporate freeloading, because the whole
| point of copyright is to _stop corporate freeloading_.
|
| [0] From what I've heard, the anti-TiVo clause in GPLv3
| is actually less strict than the FSF advertised, at least
| relative to how TiVo used Linux. I can't find the
| original article I heard this in, though!
|
| [1] Specifically, the OpenWatcom license requires
| distribution of source code whenever you _use_ a modified
| version of the software.
| freedomben wrote:
| I mostly agree with you, with one exception:
|
| > _Remember: the whole point of the GPL is to reject
| copyright, and that specifically means lots of corporate
| freeloading, because the whole point of copyright is to
| stop corporate freeloading_
|
| I don't think this is true. My understanding (which could
| be flawed) is that the whole point of the GPL is to
| _weaponize_ copyright in order to guarantee freedoms, not
| to _reject_ it (a subtle but important distinction).
|
| Also the whole point of copyright doesn't seem to be to
| stop corporate freeloading, though that is of course part
| of it. It's point is to ensure that the original creator
| has rights to benefit from the work, whether that means
| getting stolen from by a huge corporation or stolen from
| by teenagers passing memes over the internet, or adapted
| by an individual/sole proprietor as part of some larger
| work, etc. My guess is we probably agree on this part and
| the debate is probably over semantics (i.e. you might
| have meant "business in general" by "corporate" rather
| than specific corporations).
| dingnuts wrote:
| >You can defeat the Affero clause by putting the software
| behind a proxy, for example
|
| Could someone elaborate on this? This is NOT my
| understanding of the license, and it seems absurd
| considering e.g. Mastodon is AGPL but the standard
| install requires a reverse proxy[1]. If using a proxy
| defeats Affero, why would the Mastodon team do this? Are
| they stupid?
|
| [1] https://github.com/mastodon/mastodon/blob/main/dist/n
| ginx.co...
| bombcar wrote:
| It's never been tested in court, but the theory is you
| with company A run an Affero GPL (modified code) server.
| It's not accessible to anyone outside company A, except
| me, with a proxy-ish server in Company B (which may or
| may not be controlled/related).
|
| Then I'm the only user of your software, and never
| request the code, even though ten billion users use it
| via my proxy.
| singpolyma3 wrote:
| This is only gonna work with a very specific corporate
| structure, if it even works at all. Judges don't tend to
| fall for this kind of "being cute"
| TylerE wrote:
| I'm not so sure it's just being cute. Define a bright
| line difference between this API proxy and something like
| an IRC server. Fundamentally it's an RPC black box.
| Client sends a command and gets a response. How that
| response is generated the client has no way of knowing or
| differentiating. For the defense to fail, wouldn't you
| have to prove that end user C was a recipient of software
| from company A? How could this possibly be true when user
| C cannot observe even the existence of A?
|
| Like, imagine this hypothetical.
|
| Set up a server. For each unique client that exists, it
| proxies to one of two backends. One is wrapping an LGPL
| library. The other is wrapping a cleanroom non-CL
| implementation.
|
| A given user will always get one or the other. Think of
| it as being assigned off the high bit of a user hash or
| something.
|
| Which users have rights under the LGPL? Remember that
| half of them have never used the (wrapped) LGPL
| implementation, and NONE of them can tell which group
| they are in.
|
| I don't actually see the difference as being that
| distinct from the long accepted fact that a program
| compiled by a copyleft compiler or running in a copyleft
| interpreter is not itself inherently copyleft.
| kmeisthax wrote:
| The idea is that the proxy removes all the AGPL
| compliance features from the web application. So if your
| app has a View Source link that spits out all the *.php
| files on disk, your proxy blocks that link. AGPL
| prohibits you from removing parts of a program intended
| to implement a "View Source" link, but it doesn't put any
| specific limitations on the conduct of other, unrelated
| programs.
|
| The only other thing I could think of to prevent this
| would be a DMCA 1201 claim - i.e. that the view source
| link is a DRM system, and that a proxy that removes those
| links is illegal. Except all v3 licenses explicitly
| foreclose the ability to make DMCA 1201 claims relating
| to features of the software.
|
| My guess is, Mastodon used AGPLv3 primarily because the
| Affero clause scares off big tech companies, notably
| Google. I don't have access to any IRC logs or issue
| tracker comments to prove this is the case, though.
| zerocrates wrote:
| There's much that's untested about these licenses in
| practical terms. This scheme of producing the source but
| also blocking it... it's hard to see it standing up in
| court.
|
| Let's assume you modify the AGPL program, so the remote
| interaction clause kicks in. If you have the software
| provide links to the source, but you yourself also strip
| those out before any of those remote-interacting users
| can ever see or use them, I don't think a court would
| have a problem saying that you're not actually "offering
| an opportunity" for the users to download the source and
| are therefore in violation.
| not_the_fda wrote:
| [0] The anti-TiVo clause only applies to "User Product"
| defined in the GPL as a consumer device, i.e. not a
| device you sell to a business. The idea being business's
| can fend for themselves. Its perfectly valid to create
| say a medical device that is sold to hospitals and have
| it locked down and use LGPL code. The hospital actually
| wants it locked down.
| singpolyma3 wrote:
| https://sfconservancy.org/blog/2021/jul/23/tivoization-
| and-t...
| kmeisthax wrote:
| > [so], these words in GPLv3: "The information must
| suffice to ensure that the continued functioning of the
| modified object code is in no case prevented or
| interfered with solely because modification has been
| made." mean that the proprietary software that is not a
| combined work with the GPLv3'd work must also function?
|
| > Absolutely. And I wrote it specifically to do that!
|
| Welp, looks like I was wrong about that one.
| actionfromafar wrote:
| This is where things start being human and not only
| technocratic. If I, the user, have (only) an iOS device -
| how can I do this re-linking? I can't. I must get
| permission from (Apple Developer Account), buy a Mac, and
| re-sign binary blobs.
|
| "The user wouldn't be able to then run the recompiled
| application, on their device" - I think that's where we get
| into the spirit of the license. It's pretty clear the
| license was not written to mean "here's some bytes, we
| write a lot about the freedom of the user" all for it to
| end with "can't run it though".
|
| I can't understand someone carefully reading the LGPL
| license and then thinking, "great fit for a locked down app
| store distribution!"
|
| I rather think that because LGPL historically saw a lot of
| use for platforms where this is not a problem, like
| Windows, where all this relinking is pretty doable, people
| just assume its fine on iOS.
| ajross wrote:
| > I've never understood the problem with (L)GPL code on iOS
| devices. Sure, users don't have the possibility to replace
| the code on that platform. But the restriction is not imposed
| by the people distributing the code, but by external
| circumstances (Apple).
|
| That seems very forest-for-the-trees. It's true, but it
| mistakes a micro-statement of a problem (the app vendor isn't
| "at fault" for the LGPL violation) with the actual problem
| (copyleft code of any kind is effectively impossible on the
| most popular mobile platform in the industrial world).
|
| The bottom line is that it's not possible to distribute a
| binary containing *GPL code on iOS in any way remotely in
| keeping with the letter of the license. People do it anyway
| because this code is important and useful. But Apple has
| effectively banned the license and that's always going to
| lead to friction like this.
| torstenvl wrote:
| > _it 's not possible to distribute a binary containing
| *GPL code on iOS in any way remotely in keeping with the
| letter of the license._
|
| That is quite audacious to claim.
|
| Do you have a citation to any case law supporting your
| position?
|
| If not, what would be your argument?
| ajross wrote:
| It's in the text of the license? See section 6. a)
|
| https://www.gnu.org/licenses/old-
| licenses/lgpl-2.0.en.html
|
| Also of course section 9: "You are not required to accept
| this License, since you have not signed it. However,
| nothing else grants you permission to modify or
| distribute the Library or its derivative works. These
| actions are prohibited by law if you do not accept this
| License."
|
| You can't legally put copyleft stuff on the App store,
| because the recipient can't modify the results. That
| we've all as a society decided to look the other way
| doesn't change the requirements of the license.
| torstenvl wrote:
| So no case law.
|
| You've pointed me to two sections of the license, but
| neither directly says what you're claiming. Why don't you
| help us understand what your argument would be? I.e.,
| explain how you would apply the rules in the license to
| the facts of iOS distribution to reach the conclusion
| that distribution on iOS is a per se violation?
| ajross wrote:
| > explain how you would apply the rules in the license to
| the facts of iOS distribution to reach the conclusion
| that distribution on iOS is a per se violation?
|
| That's analysis is exactly backwards, and I cited the
| specific text in the license that calls it out. You can't
| distributed copyrighted works without permission, period.
|
| Apple can't ship my code, whether it be directly or in a
| Play Store app, unless I let them. The LGPL specifies the
| terms of that permission. They're clearly in violation,
| since I can't download a Play Store app and modify it.
|
| Again, we all agree to ignore this. But it's true
| nonetheless.
| torstenvl wrote:
| I'm sorry, but "issue-rule-application-conclusion" is the
| standard analytical framework for questions of this
| nature. You may feel that it's "backwards" but it is,
| objectively, simply how this works.
|
| There is no text in the license that discusses the issue
| of app stores. You have every right to jump to the
| conclusion without any analysis of how the text of the
| license applies to these facts. However, you'll of course
| understand that--by doing so--you aren't likely to
| convince anyone who doesn't already agree with you.
| ajross wrote:
| > I'm sorry, but "issue-rule-application-conclusion" is
| the standard analytical framework for questions of this
| nature.
|
| Do you, heh, have any case law to that effect? No, that's
| silly. "You're shipping my code and have to stop" is an
| open and shut case. That no one has bothered to prosecute
| such a case against an iOS app is notable, but not proof
| of anything but inertia.
| torstenvl wrote:
| See, e.g., Licea v. Caraway Home Inc., 655 F. Supp. 3d
| 954, 968 (C.D.Cal. 2023) ("Indeed, at no point does
| Plaintiff bother to explain why any of his cited
| authorities are relevant to the instant action or how
| they should apply. Every law student is taught a
| variation on the 'issue, rule, application, conclusion'
| (IRAC) method for legal analysis.").
| kelnos wrote:
| There is -- for better or worse -- precious little case
| law on the GPL and LGPL. All we have to go on is the
| advice of lawyers and our own judgment.
| fragmede wrote:
| Within limits, all it takes to get the OK from Tim Cook is
| $99/yr to the Apple Developer Program. Which isn't $0, but
| the LGPL doesn't say someone else can't charge money to press
| the button. You don't get arbitrary code execution for those
| $99, but you get enough access to playback video. You'd have
| to create your own app and get it blessed by Apple in order
| to distribute it to other people, but doesn't that satisfy
| the letter of the law here? As a 3rd party developer with my
| own developer account, I can get the source and the object
| code and run my own binary that links against it on the same
| platform, iOS.
| kelnos wrote:
| > _I 've never understood the problem with (L)GPL code on iOS
| devices. Sure, users don't have the possibility to replace
| the code on that platform. But the restriction is not imposed
| by the people distributing the code, but by external
| circumstances (Apple)._
|
| In the case of the App Store, Apple is the one doing
| distribution, so Apple must also comply with the terms of the
| license (in addition to the app developer). Apple has decided
| they will not do that (that is, people they distribute to
| will not have the ability to modify the LGPL code, relink the
| final executable, and run it on their devices), so Apple
| cannot legally distribute binaries that contain LGPL code.
|
| It only makes sense, then, that Apple should preemptively
| reject apps that link in LGPL code, as they know that they
| will not abide by the licensing terms.
|
| > _If I have the OK from Tim Cook and all the secret signing
| keys, I can compile and run anything I want on my iOS device.
| And even without that, if somebody provides all the object
| files of non-LGPL code and build instructions, I can replace
| the LGPL code and run my own version outside of the app
| store._
|
| That's not permitted by the license. The (L)GPL prohibits a
| third party from adding extra conditions to exercising the
| rights granted in the license. "Pay Apple for a developer
| account and get their permission" is an extra condition. Even
| if there is a jailbreak-y method of getting around the extra
| conditions, I don't think that would fly.
|
| > _Often when people ban (L)GPL code, its just a pretext,
| because they don 't want to deal with the complexities or for
| other reasons._
|
| Agreed, but I'm not convinced this is one of those cases.
| quotemstr wrote:
| The tech industry runs on myth and superstition more than most
| people will admit. One persistent myth is the special role of
| "linking" in propagating "derived work" copyright status. Are
| we really supposed to believe that if non-copyleft code A is
| tightly coupled with copyleft code B, then the copyleft _does_
| propagate to A if we summon the ld-linux.so.2 demon for dynamic
| linking and _doesn 't_ propagate if A uses B via system(2) and
| a pipe? Ridiculous. Whether A is a derivative work of B has to
| do with the extent to which A is coupled to B in particular,
| not the mechanism of this coupling.
|
| Personally, I've always found it hard to believe that merely
| using, e.g. libreadline (or Linux EXPORT_SYMBOL_GPL) really
| makes one program a derivative work of another. Is there any
| actual legal precedent for mere dynamic linking propagating
| copyleft? Common sense suggests that, no, linking to
| libreadline or libmysql or whatever doesn't make a program that
| does something totally different a derivative work.
|
| Has the linking-propagates-copyleft theory ever actually been
| tested? Might we have been making life hard for ourselves for
| decades for no actual reason?
| gumby wrote:
| The issue 'One persistent myth is the special role of
| "linking" in propagating "derived work" copyright status' has
| nothing to do with GPL.
|
| If you use _any_ 3P library it's a derived dependency by law.
| Is that what you are arguing? It's settled law at this point.
|
| MS lets you link against their DLLs but only on their
| platform. You might pay for a special library, but you have
| to pay them money for programs that link against it (actually
| does anybody do that any more?). GPL code is no different in
| any way except instead of paying the FSF cash or buying a
| Windows OS you agree to provide the user the freedom to
| change the code.
| quotemstr wrote:
| > If you use any 3P library it's a derived dependency by
| law. Is that what you are arguing? It's settled law at this
| point.
|
| Is it? So if I, the author of non-copyleft A, want to use
| copyleft library B, it's illegal if I use `dlopen` but
| legal if I use a socket or a pipe? That's absurd. Either
| both are illegal or both are legal, and I've yet to see
| evidence that it's the former.
|
| IOW, I've yet to see evidence that licenses apply across
| dlopen bounds. It's a meme in our industry that it does,
| but does it _really_? Where 's the data?
| gumby wrote:
| "Where is the data?" Have you never used third party code
| that you didn't compile yourself?
|
| Hell, Unity itself (the topic of this article) is an
| example. Labview. Some code for talking to a spectrometer
| we bought for our lab last month. It's extremely common.
| People used to sell libraries to do various computations
| and charge royalties for their use. Probably they still
| do but I don't work in that kind of world any more.
|
| You may call it absurd if you like but that's how the
| system works. The GPL and LGPL deliberately do _not_
| break new ground in that regard. What was /is novel about
| them is not using an exchange of money, but rather other
| value instead. No more, no less.
| quotemstr wrote:
| > Have you never used third party code that you didn't
| compile yourself?
|
| Free software is different.
|
| Consider the GPLed libmysql. I can _already_ freely copy
| libmysql from system to system in either source or binary
| form. The GPL grants me permission to do that. Fine. Now
| I copy libmysql.so to /usr/lib and my non-copyleft
| libproprietary.so to /usr/lib alongside it. Also allowed.
| But magically, the moment the dynamic linker loads
| libproprietary.so into the same address space as
| libmysql.so, I've broken copyright law?
|
| Yeah, I know that's the FSF's interpretation. I don't buy
| it, and here's why: this interpretation followed to its
| logical conclusion makes huge swaths of the free software
| ecosystem illegal. See, the FSF theory is that
| libproprietary.so becomes a derivative work of
| libmysql.so because it calls APIs provided by
| libmysql.so. Maybe the FSF is right. Maybe they're wrong.
| If they're right, though, why should it matter _how_ I
| use libmysql.so 's APIs? Do socket() and connect() make
| libproprietary.so not a derivative work? Why? I can use
| an API over a socket too --- and if using an API makes my
| program a derivative work, then every proprietary program
| that talks to MySQL is in trouble. This conclusion is
| absurd: therefore, our premises are wrong.
|
| You might say, "well, MySQL's socket API is obviously for
| general purpose use". So is libreadline's. So what?
| Either calling a public API propagates copyleft or it
| doesn't. Differentiating between calling APIs via
| dlopen() and via socket() makes no sense. I know the
| industry behaves as if there were a difference, but
| legally, is there? Show me the case law.
|
| The reason I can't just download LabVIEW and run it isn't
| that it's a library: it's proprietary software! I don't
| have permission to have it on my machine except by
| following the rules of the LabVIEW license. I don't need
| permission to have libmysql.so
| fluoridation wrote:
| >Consider the GPLed libmysql. I can already freely copy
| libmysql from system to system in either source or binary
| form. The GPL grants me permission to do that. Fine. Now
| I copy libmysql.so to /usr/lib and my non-copyleft
| libproprietary.so to /usr/lib alongside it. Also allowed.
| But magically, the moment the dynamic linker loads
| libproprietary.so into the same address space as
| libmysql.so, I've broken copyright law?
|
| Mmh... The GPL and copyright are about information
| distribution. You, as someone who owns their copy of
| libmysql.so and libproprietary.so, can do whatever you
| want with them. They're on your hardware and no one can
| tell you what you can order your hardware to do with the
| information that's on it. The question is, if you write a
| program that uses them both and you share that program
| with the world, how are you supposed to license that
| program? I.e. What rights are you supposed to give the
| users of that program?
|
| So the question of whether you've broken copyright law
| depends on how you've licensed the program that links to
| both libmysql.so and libproprietary.so. If the program is
| closed source, then yes, you've broken copyright law. If
| the program is GPL'd then, I don't know. Maybe you have,
| but I don't know who could sue you for making a GPL'd
| program that depends on a closed source library that you
| don't have the source for.
| quotemstr wrote:
| > If the program is closed source, then yes, you've
| broken copyright law.
|
| My point is that although many believe that linking
| proprietary code and GPL code into the same process
| breaks copyright law, it's not clear that the law
| _actually_ forbids it. https://tech.popdata.org/the-gpl-
| license-and-linking-still-u... is one analysis by someone
| else skeptical of the FSF's position.
| fluoridation wrote:
| I would argue that the act that makes a piece of software
| "derivative" of another is not loading them both onto the
| same address space (since that's a symmetric relation
| anyway), but whether making one depend on the other
| having a specific behavior. If A.so provides foo(int)
| with some contract C and B.so depends on an
| implementation of foo(int) that matches the contract C,
| then arguably B.so is derivative of A.so, and the more
| facilities A.so provides and B.so assumes are available,
| the stronger that argument becomes. Whether the way A.so
| and B.so communicate is through a calling convention, a
| pipe, or a network connection, is largely an
| implementation detail.
| quotemstr wrote:
| I have two points:
|
| 1) it's not clear your interpretation of what makes
| software "derivative" is correct. One interesting
| analysis is https://studylib.net/doc/18120956/triggering-
| infection--dist......
|
| 2) if you _are_ correct, then isn 't it a violation of
| copyright law to use a socket or a pipe to talk to a GPL
| program? For example, if I execute popen("parallel ..."),
| I'm using a pipe to talk to a GPLed program (assuming
| "parallel" is GNU parallel). I expect this program to
| adhere to a specific command line interface. My program
| won't work with anything else. Is my program violating
| the GPL by running GNU parallel as a subprocess? Most
| people would say "no". This position seems incoherent to
| me.
|
| One of two conditions must then hold: either a) dlopen
| has legal significance, or b) much of the Linux ecosystem
| is out of compliance with the GPL because it attempts to
| use pipe() to circumvent the GPL and this approach
| doesn't actually work. Which is it?
| nirimda wrote:
| > One of two conditions must then hold: either a) dlopen
| has legal significance, or b) much of the Linux ecosystem
| is out of compliance with the GPL because it attempts to
| use pipe() to circumvent the GPL and this approach
| doesn't actually work. Which is it?
|
| Afaik the FSF agrees with your dichotomy and expresses
| the latter opinion. Take for instance their faq "You
| cannot incorporate GPL-covered software in a proprietary
| system. ... However, in many cases you can distribute the
| GPL-covered software alongside your proprietary system.
| To do this validly, you must make sure that the free and
| nonfree programs communicate at arms length, that they
| are not combined in a way that would make them
| effectively a single program. The difference between this
| and "incorporating" the GPL-covered software is partly a
| matter of substance and partly form. The substantive part
| is this: if the two programs are combined so that they
| become effectively two parts of one program, then you
| can't treat them as two separate programs. So the GPL has
| to cover the whole thing."
|
| In another question, they address the notion of what
| might be considered a single combined porogram. "It
| depends on how the main program invokes its plug-ins. If
| the main program uses fork and exec to invoke plug-ins,
| and they establish intimate communication by sharing
| complex data structures, or shipping complex data
| structures back and forth, that can make them one single
| combined program. A main program that uses simple fork
| and exec to invoke plug-ins and does not establish
| intimate communication between them results in the plug-
| ins being a separate program.
|
| "If the main program dynamically links plug-ins, and they
| make function calls to each other and share data
| structures, we believe they form a single combined
| program, which must be treated as an extension of both
| the main program and the plug-ins. If the main program
| dynamically links plug-ins, but the communication between
| them is limited to invoking the 'main' function of the
| plug-in with some options and waiting for it to return,
| that is a borderline case.
|
| "Using shared memory to communicate with complex data
| structures is pretty much equivalent to dynamic linking."
|
| So I don't think that the FSF intends that you can use a
| technical means to escape linking. You cannot take a GPL
| library and write a pair of libraries which expose its
| functions via a socket because the result would almost
| certainly involve "function calls to each other and
| share[d] data structures".
|
| https://www.gnu.org/licenses/gpl-faq.html
|
| As to whether this puts into jeopardy anyone in
| particular who uses Linux or libmysql in proprietary
| systems without additional licences, well, that is a
| different matter. The FSF's interpretation of the GPL
| tells you something about when the FSF might sue you and
| about what revisions might be made to the GPL in the
| future. But it doesn't tell you about when the copyright
| holders of Linux or libmysql might sue you, or what they
| will do if there's a GPL v5.2 released tomorrow.
| fluoridation wrote:
| I would argue that yes, you're not working around the GPL
| by going through a pipe. Your program still doesn't work
| if the remote process gets killed, so it's dependent on
| it.
|
| > b) much of the Linux ecosystem is out of compliance
| with the GPL because it attempts to use pipe() to
| circumvent the GPL and this approach doesn't actually
| work.
|
| What do you have in mind in particular?
| toyg wrote:
| _> I don 't need permission to have libmysql.so _
|
| Er, dude, you do. A Free license doesn't mean there is no
| license. If you obtain libmysql.so and use it _in any
| way_ , you have to respect the license or you're in
| breach of copyright law.
|
| The fact that free (re)distribution is allowed by the
| license does not mean that the use of it _in any way_ is
| not restricted.
|
| _> this interpretation followed to its logical
| conclusion makes huge swaths of the free software
| ecosystem illegal_
|
| That might well be. Free licenses are abused every day,
| as people don't really know what this or that license
| requires. They even routinely strip copyright statements
| on MIT/BSD code, which is literally the only thing one is
| not supposed to do. But just because people get away with
| speeding over the limit on most days, it doesn't mean
| that the speed limit is not legally enforceable.
| quotemstr wrote:
| > If you obtain libmysql.so and use it in any way, you
| have to respect the license or you're in breach of
| copyright law.
|
| We're talking about following the GPL to the letter with
| respect to libmysql.so. The GPL says nothing about what I
| can do with a program on my system not covered by the
| GPL.
| nirimda wrote:
| > If they're right, though, why should it matter how I
| use libmysql.so's APIs? Do socket() and connect() make
| libproprietary.so not a derivative work? Why? I can use
| an API over a socket too --- and if using an API makes my
| program a derivative work, then every proprietary program
| that talks to MySQL is in trouble.
|
| As far as I know, the FSF takes the view that linking is
| a logical concept not a technical one, and so
| communicating via IPC is just as much of a problem as
| loading a program into your own addressable memory.
|
| > This conclusion is absurd: therefore, our premises are
| wrong.
|
| I don't think you've demonstrated that it's absurd. For
| instance, it could be that MySQL does not believe it is a
| problem, and does not intend for it to be a problem, and
| will never sue for it - but that MySQL is wrong as a
| matter of law, and one day the FSF will sue someone in
| court and win and the Oracle lawyers will realise they
| have new opportunities for financial gain. Personally, I
| think that reality is more like this - the FSF and Oracle
| have different ideas about what it means to release code
| under the GPL and so the freedoms you get from the FSF
| are different from the freedoms you get from Oracle, and
| it's unclear to me what will hold up in a court of law. I
| certainly don't think there's anything absurd about the
| notion that different agents have different intents and
| conflicting understandings. (Note that I take the notion
| of freedom to include the confidence that I won't be sued
| by a rational agent for doing something, regardless of
| whether I could plausibly win the case or not.)
|
| > I know the industry behaves as if there were a
| difference, but legally, is there? Show me the case law.
|
| I don't think it makes a difference whether the case law
| is there. The difference is made by whether you're
| willing to go to court over it. If there is a chance that
| you will win a case, and there is a chance that you will
| loose a case, and that if you lose the case you will have
| to spend the next six months on full time development
| just to get back where you were before hand, then you
| might say "even though my lawyers say there is an 80%
| chance that we will win, I would rather use this BSD
| alternative, because the risk of that 20% are
| existential".
|
| So, fundamentally, this is a case of put your money where
| your mouth is. If you think the GPL does something
| different than what "industry" thinks it does, then make
| your business, make your millions, and dare someone to
| sue you. No one else has an obligation to do that just
| because you haven't seen the case law.
|
| > I don't have permission to have it on my machine except
| by following the rules of the LabVIEW license. I don't
| need permission to have libmysql.so
|
| Btw, here you have a false premises. You don't have
| permission to copy libmysql.so except by the terms of the
| licence. I think you've made a mistake. Let's go back.
| You said "I can already freely copy libmysql from system
| to system in either source or binary form. The GPL grants
| me permission to do that." But now you're claiming that
| the GPL's grant of permission is so absolute that you
| don't need the permission that it grants. In fact, the
| terms of the licence are limited, and the question is
| only to what extent they are limited.
|
| In any case, there is one important consideration. And
| that is the intent of the FSF. If the terms of the GPL
| fail to have the legal consequence they intend, and they
| can modify the GPL to have the legal consequence they
| intended, then you can be sure they will. And if Oracle
| has a different intent, and likes the legal consequences
| that the GPL has, then they might continue to use the
| unchanged licence. But arguing about whether the GPL does
| to the FSF's code what the FSF wants the GPL to do is
| more about arguing about whether it is buggy, then
| arguing about the feature set. You are well advised to
| listen to the FSF's interpretation if you want to rely,
| indefinitely into the future, on an up-to-date version of
| the FSF's code. But the FSF's interpretation might not
| really be as important when it comes to Linux or MySQL or
| any of the other GPLed code bases out there.
| poizan42 wrote:
| What is the point you are trying to make here? You can't
| use a proprietary library without a license because you
| can't distribute it. Whether you can have code linking to
| the proprietary library without distributing the
| proprietary library has been largely irrelevant to the
| makers of those libraries since you wouldn't be allowed
| to use that functionality without either the distributor
| or the user paying for a license anyways.
| belorn wrote:
| Distribution is not required for copyright infringement.
| The creation of a derivative work is a separate right in
| copyright.
|
| Copyright law has however implemented exceptions in the
| form of interoperability. The distinction between
| creating a derivative work, or having two works
| communicating with each other, is a relative fuzzy one.
| tzs wrote:
| I'm having a hard time figuring out what either of you
| are actually talking about.
|
| He's talking about various ways code written by one party
| may invoke code on the same computer written by someone
| else but not saying exactly how those two chunks of code
| came to be on the same computer running at the same time.
| Without knowing all the people involved in that it is not
| possible to say what copyright law says about who needs
| to get permission from whom.
|
| You've talked about "derived dependencies by law" but
| "derived dependencies" is not a term I've come across in
| US copyright law.
|
| A lot of free/open source discussion (and sometimes the
| licenses themselves) tends to use terms that have
| "derived" in them but mean some sort of vague superset of
| what copyright law means by "derivative work".
|
| In particular, if work X depends on work Y, even to the
| point that X is not really useful unless used with Y,
| that does not necessarily make X a derivative work of Y.
| That's why game console makers had to use DRM to stop
| other companies from making cartridges for they game
| consoles. Even though the software in the cartridges was
| utterly dependent on the code in the console to do
| anything the cartridges were not derivative works.
|
| To be a derivative work of Y, X must incorporate some or
| all of Y. Suppose for example Y is a text to speech
| library which exports a function "int speak(char *
| text)". If I write a file, greet.c, that contains this:
| #include "y_speech_lib.h" int main() {
| speak("Hello, World!"); return 0; }
|
| greet.c is not a derivative work of Y because I have not
| included any copyrightable elements of Y in greet.c. If I
| compile greet.c and link it with Y the resulting a.out is
| a derivative work of Y.
|
| I can license greet.c under any license I want and
| distribute it under any terms I want without having to
| worry about Y's license as far as possible liability to
| me for direct copyright infringement goes. I'll cover
| indirect infringement later.
|
| If I want to distribute a.out then I do need to worry
| about Y's license, because a.out is a derivative work of
| Y.
|
| If someone else makes an a.out from my greet.c and Y they
| are making a derivative work, and need permission (maybe
| [1]) from me and from Y's copyright owner.
|
| It is possible to be an indirect copyright infringer.
| There are a few different kinds of indirect infringement,
| such as vicarious infringement and contributory
| infringement. What they all have in common is for someone
| to be liable as an indirect infringer there must be a
| direct infringement for them to be indirectly liable for.
| If there is no direct infringer there cannot be an
| indirect infringer.
|
| Since most open source licenses only impose requirements
| when you distribute code, doing stuff with it on your own
| computer just for you own use will usually not be a
| direct infringement, and hence no possibility of indirect
| infringement for those who supplied you with other code
| that you used with the open source code code.
|
| Even if you combine my greet.c with someone else's code
| on your computer and distribute the resulting binary in
| violation of that other code's license (making you a
| direct infringer) I'd be OK unless (1) I had the right
| and ability to control you and received a direct
| financial benefit from your infringement, (2) I
| distributed greet.c with the object of promoting its use
| for such infringement and clearly expressed that or took
| affirmative steps to encourage it, or (3) greet.c has no
| other substantial uses that are not infringing.
|
| [1] I say maybe because if they are just compiling and
| linking copies of greet.c and Y that they legally own in
| order to use them on their machine they might not need
| permission. US copyright law contains an exception for
| things that are an essential step to utilize a program on
| a machine (17 USC 117) and they don't do anything else
| with it like distribute it.
| simiones wrote:
| > greet.c is not a derivative work of Y because I have
| not included any copyrightable elements of Y in greet.c.
|
| I think this is very much debatable, and I believe the
| FSF at least takes the position that greet.c _is_ a
| derived work of Y since it is designed to depend on Y.
| Even more, their position is that a program like this:
| #include <stdlib.h> int main() { cre
| ate_complex_c_code_using_gcc_specific_extensions("./inter
| mediate.c"); system("gcc -o intermediate
| ./intermediate.c"); system("./intermediate");
| }
|
| Is quite possibly a derived work of GCC, since it depends
| critically on communicating with GCC using a very complex
| and specific data interchange format (the GCC-specific C
| source code). Note that this is not including any portion
| of GCC itself, even after compilation.
|
| Now, this type of thing has never been tested in a court
| of law as far as I know, so it's difficult to say whose
| interpretation of copyright and its implications is
| actually correct. But this is similar to the idea that if
| you were to write an original novel that uses characters
| or very recognizable aspects of, say, The Lord of the
| Rings, you'd be creating a derived work (and thus
| permission from the Tolkien estate), even if you didn't
| include any part of the original longer than "Galadriel".
| kelnos wrote:
| > _If I compile greet.c and link it with Y the resulting
| a.out is a derivative work of Y._
|
| Link it how, though? If you statically link it with Y,
| then I can see the argument that a.out is a derived work,
| because it literally contains all of Y in it.
|
| But if you dynamically link it, a.out contains no more of
| Y than greet.c does. Are you asserting that a.out is
| still a derived work of Y in this case as well?
| LeifCarrotson wrote:
| This is a question of law, not math - the property
| doesn't have to be commutative or even consistent.
|
| Licenses apply across certain kinds of linking and not
| others because that's what was in the document you agreed
| to when you installed the copyleft code. In order to run
| the code, you have to accept the terms of the contract.
| Those terms can require almost anything the author wants.
| In this case, the terms specify propagation over dlopen
| and not over a socket or pipe. They could just as easily
| specify the opposite! It would be less sensible, but
| perfectly possible.
| quotemstr wrote:
| > Licenses apply across certain kinds of linking and not
| others because that's what was in the document you agreed
| to when you installed the copyleft code.
|
| The GPLv2 (for clarity: GPLv3 is more verbose but
| communicates the same idea) says:
|
| > 3. You may copy and distribute the Program (or a work
| based on it, under Section 2) in object code or
| executable form under the terms of Sections 1 and 2 above
| provided that you also do one of the following: > a)
| Accompany it with the complete corresponding machine-
| readable source code, which must be distributed under the
| terms of Sections 1 and 2 above on a medium customarily
| used for software interchange; or, > b) Accompany it with
| a written offer, valid for at least three years, to give
| any third party, for a charge no more than your cost of
| physically performing source distribution, a complete
| machine-readable copy of the corresponding source code,
| to be distributed under the terms of Sections 1 and 2
| above on a medium customarily used for software
| interchange; or, > c) Accompany it with the information
| you received as to the offer to distribute corresponding
| source code. (This alternative is allowed only for
| noncommercial distribution and only if you received the
| program in object code or executable form with such an
| offer, in accord with Subsection b above.)
|
| Where does this license talk about linking? Why should
| the GPL apply to _my_ program that _calls_ libreadline
| when I 'm distributing the two separately and combining
| them at runtime? And more importantly, why does a
| combination involving dlopen() summon the copyright
| demons but socket() not? The distinction makes no sense.
|
| I'd like to see actual case law showing that if I
| dlopen() libreadline from a proprietary program, dlsym()
| a function, and call it, then I've violated copyright
| law. Show me one example of the legal system adopting
| this interpretation.
| smw wrote:
| Because if you don't agree to the GPL's interpretation of
| it, then you haven't agreed to the license for the
| library and you don't have permission to distribute it?
|
| (edited)
|
| I think this is the magic legal judo of the (L)GPL that
| makes it work. Regardless of your feelings about the
| license, it's extraordinarily clever!
|
| Note that if the license said you had to, for instance,
| share x% of your revenue with the licensor, that's not
| part of copyright law either, but it's still probably a
| legal license.
| simiones wrote:
| Neither the GPLv2 nor the GPLv3 define what constitutes a
| derivative work or make any claims about linking in the
| normative parts of the license.
|
| Let's assume that tomorrow some courts were to find that
| two separate works can link to each other without being
| considered derived works of one another, and without the
| whole being considered a derived work of either part.
| Nothing in the text of the GPLv2/3 would then prevent you
| from writing a program which links to GCC, and
| distributing it under a fully proprietary license (as
| long as you distribute the sources of the version of GCC
| you're using, of course).
|
| There is one tiny reference to linking in the non-
| normative parts of the GPL, the "How To Apply These Terms
| To Your New Programs" section after the explicit "END OF
| TERMS AND CONDITIONS":
|
| > If your program is a subroutine library, you may
| consider it more useful to _permit linking proprietary
| applications with the library_ [emp. mine]. If this is
| what you want to do, use the GNU Lesser General Public
| License instead of this License.
|
| This may suggest that the writers of the GPL believe this
| would not be allowed under copyright law, but being
| outside the normative area of the license, seems unlikely
| to be an impediment in court.
| juped wrote:
| it doesn't, full stop, but the FSF has been pushing its
| maximalist theories which would not survive a second in
| court for decades now.
|
| what may be more relevant is that the use of the GPL is
| evidence that the author (possibly) believes in
| maximalist FSF theories. and therefore might not be
| someone whose libraries you want anywhere near your work,
| for avoidance of potential disputes.
| poizan42 wrote:
| > If you use any 3P library it's a derived dependency by
| law. Is that what you are arguing? It's settled law at this
| point.
|
| Not it's definitely not. For B to be a derivative work of A
| it needs to include copyrightable elements of A. But if B
| merely dynamically links to A then it only contains
| knowledge of the API surface of A. And SCOTUS refused to
| rule on the copyrightability of APIs in Google LLC v.
| Oracle America, Inc. In the EU APIs seems to be explicitly
| called out as non-copyrightable by Directive 2009/24/EC
| Article 1(2):
|
| > 2. Protection in accordance with this Directive shall
| apply to the expression in any form of a computer program.
| Ideas and principles which underlie any element of a
| computer program, including those which underlie its
| interfaces, are not protected by copyright under this
| Directive.
| gumby wrote:
| An utterly irrelevant side point since the whole question
| is the _use of the implementation_ not the API.
|
| If you call write() in Microsoft's libc you must follow
| Microsoft's license terms or you don't have the right to
| use it. If you call glibc's write() the same applies. And
| if you don't like glibc's terms you are free to, say,
| install bsd's libc or write your own write()
| implementation (which probably just does a system call
| anyway).
| juped wrote:
| I don't agree with you but I appreciate you providing me
| with comments like this to cite when I try to convince
| people "yes, FSF are really that maximalist; no, that's
| not a 90s relic they moved on from".
| freedomben wrote:
| > I don't agree with you but I appreciate you providing
| me with comments like this to cite when I try to convince
| people "yes, FSF are really that maximalist; no, that's
| not a 90s relic they moved on from".
|
| unless you make sure that gumby is speaking for the FSF,
| then that comment does not provide evidence that the FSF
| believe that. It's merely evidence that gumby does.
|
| I don't understand why people are so quick to take
| somebody's personal opinion and ascribe it to whatever
| organization(s) they happen to belong to. This sort of
| fallacy is why we constantly have to suffer through the
| "I speak only for myself, not my organization"
| disclaimers
| gumby wrote:
| > unless you make sure that gumby is speaking for the
| FSF, then that comment does not provide evidence that the
| FSF believe that.
|
| And indeed I do not speak for the FSF and never have.
| Andrew_nenakhov wrote:
| And yes, _it is a good thing_.
|
| Some things shouldn't change just because entitled people
| are inconvenienced by them.
| chme wrote:
| > An utterly irrelevant side point since the whole
| question is the use of the implementation not the API.
|
| I find this interesting, and maybe I am just a bit
| confused. But here is what I am wondering now.
|
| If it is not about the use of an API but about the use of
| the implementation, then that would mean that the end-
| user that is running the application which dynamically
| links to a proprietary library on the end-users pc the
| one violating the license terms, not the developer that
| distributed their code without distributing the
| proprietary library itself.
|
| And if the developer has the rights to distribute the
| library, because it is under GPL, then they could do so,
| and would not violate the license terms, because they are
| not doing the dynamic linking and using of the
| implementation, that would happen only when the end-user
| starts the application.
|
| I never heard about any case against end-users, that for
| instance used the proprietary Nvidia kernel module,
| compiled and linked on each end-user's PC.
|
| I don't think that works that way, there has to be more
| to that than just the _usage of the implementation_ that
| triggers the license violation.
| singpolyma3 wrote:
| > If it is not about the use of an API but about the use
| of the implementation, then that would mean that the end-
| user that is running the application which dynamically
| links to a proprietary library on the end-users pc the
| one violating the license terms, not the developer that
| distributed their code without distributing the
| proprietary library itself.
|
| yes
|
| > And if the developer has the rights to distribute the
| library, because it is under GPL, then they could do so,
| and would not violate the license terms, because they are
| not doing the dynamic linking and using of the
| implementation, that would happen only when the end-user
| starts the application.
|
| If they distribute it together though then it becomes an
| aggregate work
| anthk wrote:
| No, you are wrong. Libraries have an usage _license_ on
| linking. Don 't comply it, then reimplement your _own_
| readline and ship that instead of GNU readline. Period.
| Motif and Lesstif was an infamous case back in the day.
| Heck, or using Wine DLL 's under Windows instead of the
| ones bundled from Microsoft.
| poizan42 wrote:
| A third party library can claim whatever it wants in its
| license, that doesn't make it enforceable. There needs to
| be some mechanism that causes the terms of the license to
| apply to you. If you don't distribute any copyrightable
| parts of a third party library then you (may?) not be
| under any obligation to adhere to its license.
| armada651 wrote:
| Even if you don't personally violate the license, the
| license may still be enforceable against the users of
| your program. When the user executes your program and it
| loads other libraries into its memory space, then it
| definitely has become a derivative work and the terms of
| the libraries will apply to the program as a whole.
| simiones wrote:
| At least in the USA, the copying of a program you legally
| received into working memory doesn't require a license of
| any kind, it is a type of fair use. I believe the EU has
| an explicit exception to copyright for the same reason.
| So I don't think any problem would arise when running the
| programs.
|
| The only pertinent question is whether a program B
| designed to require library A is a derived work of
| library A or not - and this is a question for the
| copyright courts, the license of library A has nothing to
| say about this.
|
| Now, I think even if it were established that program B
| is _not_ a derived work of library A, it could be
| possible for library A to have a license that says
| "you're not allowed to distribute this library to others
| unless both you and they agree to never link program B or
| works derived from it with library A". The GPL could be
| modified to say something like this, and it may still
| match its original goals - though it may be more
| difficult to litigate this type of license term (in many
| countries, license or contract terms can be declared too
| onerous and be ignored).
| pests wrote:
| > I think even if it were established that program B is
| not a derived work of library A
|
| I don't think it ever will be.
|
| > program B designed to require library A
|
| How do you design program B to require A, without
| inspiration from A?
|
| I believe you can't. For a silly example, take a puzzle
| peice. To integrate support for your puzzle in my work,
| I'm gonna have to copy some of your edges.
| armada651 wrote:
| > At least in the USA, the copying of a program you
| legally received into working memory doesn't require a
| license of any kind, it is a type of fair use. I believe
| the EU has an explicit exception to copyright for the
| same reason. So I don't think any problem would arise
| when running the programs.
|
| My point wasn't about copying into memory being a license
| violation, rather the fact that you're combining two
| works together into a single program that violates the
| license of one of the works. Who is liable for the
| violation in that case? The user who combined the works
| together or the developer who created a program that
| instructs the user to combine those works together?
|
| Perhaps you're selling a book that's derivative of
| Stephen King's novels, but instead of actually including
| text from his novels you insert pages that just say
| "insert chapter 5 from the Shawshank Redemption here".
| Even though it contains instructions to create a
| derivative work, it is not in itself a derivative work.
|
| However if the reader follows those instructions and
| creates a completed work by inserting those chapters as
| instructed. That completed work definitely is a
| derivative work of Stephen King's novels.
| jopsen wrote:
| I thought that the license for B says you can't distribute it
| along side A.
|
| Not that copyright propagates.
|
| Obviously, a zip archive containing A and B is a derived work
| of B. Hence, license of B can say you can't distribute such
| works.
|
| Does distributing A without B make any sense?
| im3w1l wrote:
| I have seen stuff like this. Audio programs asking you to
| specify the location of lame_enc.dll. Emulators asking you
| to specify location of some bios.
| anthk wrote:
| The BIOS it's a different case. That's left to the user.
| Also, the usage of the BIOS happens under emulation, not
| the main machine. For instance, FUSE with the Sinclair ZX
| ROM's instead of OpenSE. or Vice with the Commodore
| BIOSes instead of shipping C64 OpenBIOSes.
| quotemstr wrote:
| > I thought that the license for B says you can't
| distribute it along side A.
|
| Nope. The GPL explicitly says
|
| > In addition, mere aggregation of another work not based
| on the Program with the Program (or with a work based on
| the Program) on a volume of a storage or distribution
| medium does not bring the other work under the scope of
| this License.
| jameshart wrote:
| > Obviously, a zip archive containing A and B is a derived
| work of B.
|
| It's not obvious that any copyright attaches to a zip
| archive at all, any more than hanging two paintings on a
| wall makes a derived work copyrightable wall.
|
| To be a derived work something still has to be a 'work'.
|
| A distribution license can restrict how you are allowed to
| distribute a work because it can directly restrict your
| behavior not because it propagates and applies to the
| container you distribute it in.
|
| That is it can just say 'you can't distribute this bundled
| up with other things', in much the same way as it can say
| 'you can't distribute this without the copyright notice',
| or 'you can't distribute this on Wednesdays'.
| singpolyma3 wrote:
| Dynamic linking will result in a program _in memory at
| runtime_ that is under the copyleft terms.
|
| The separate pieces on disk are of course as you say.
| Y_Y wrote:
| For clarity, I presume you're talking about L(ibrary)GPLv2.0
| published[0] in June of '91, since afaik there was never an
| LGPLv1.
|
| Anyway, do you think it's good or bad if Unity is stopping
| people from potentially deploying to e.g. iOS when this would
| violate the LGPL, even if the responsibility for the violation
| would not lie with Unity?
|
| [0] https://www.gnu.org/licenses/old-licenses/lgpl-2.0.html
| simiones wrote:
| Given that Unity itself also uses LGPLv2.0 dependencies in
| its own iOS version, it seems clear that at least Unity
| believes that there is no issue deploying LGPLv2.0 code to
| iOS.
| dagmx wrote:
| Or they've dual licensed the libraries in question.
| simiones wrote:
| You're suggesting they have obtained permission from the
| copyright holders of, say, libiconv, to distribute their
| code under a non-LGPL license?
| doctorpangloss wrote:
| I don't think there are any LGPL licensed libraries
| linked or distributed by a Unity iOS build. Neither you
| nor I have looked carefully, but it's almost certainly
| not the case.
|
| With regards to libiconv, which I don't know if Unity iOS
| builds use it, there is a BSD implementation of it, which
| is almost certainly the case also with what iOS uses.
|
| I can't speak to the work the author of this blogpost did
| with regards to investigating the usage of the specific
| LGPL libraries. The specific examples specified would all
| make sense as strictly used by the Editor.
|
| My opinion is that if you are looking for wholesale
| license violations by giant corporations like Unity,
| libraries are the wrong place. Huge corporations launder
| license violations by line-by-line rewriting the code and
| pretending their implementation is original.
| simiones wrote:
| The authors of the article claim that the Unity runtime
| uses (some of) those libraries, and that it is being used
| on iOS as well. You're right of course that I have not
| done any independent research on it, and so they may be
| lying or wrong for all I know.
|
| However, even if Unity is not using those libraries in
| the iOS runtime but does use them somewhere else, that
| still seems that they were arbitrary in their enforcement
| of the rules, since the VLC packages mentioned here were
| not being distributed for iOS _at all_. So they were
| certainly not using LGPL on iOS either.
|
| I'd also mention that I'm not claiming that Unity is
| breaking the LGPL. I'm rather more of the opinion that
| distributing LGPL apps for iOS is not in contradiction
| with any of the terms of the LGPL, and that Unity thinks
| so as well.
| debugnik wrote:
| > The authors of the article claim that the Unity runtime
| uses (some of) those libraries, and that it is being used
| on iOS as well.
|
| The article doesn't mention iOS or Apple even once, they
| in fact mention they only had assets for Windows, UWP and
| Android as three different packages, so everyone here
| thinking Unity is blocking the packages because of iOS
| has completely missed the context.
| doctorpangloss wrote:
| > The authors of the article claim that the Unity runtime
| uses (some of) those libraries...
|
| Ultimately I sympathize with the author, and this is not
| meant to pass a subjectively negative judgement, I know
| the author didn't unpack a Unity iOS IPA and carefully
| check if any of the libraries are definitively LGPL and
| if they were definitively not cross licensed, that would
| be a waste of his time.
|
| > distributing LGPL apps for iOS is not in contradiction
| with any of the terms of the LGPL
|
| I don't want to make the author of the LGPL, who is
| commenting in this thread, regret commenting. There's a
| phrase he uses that makes it clear to me what its intent
| is, "right to repair." It comes down to whether or not
| you think it's impracticable to replace a library in an
| iOS app. For the average user it obviously is.
|
| Is it practicable for sophisticated users? You can
| probably get the app bundle, replace a .dylib in an
| embedded Framework, resign it, and use the app bundle on
| your development enrolled device. But then you will lose
| a lot of functionality, like push notifications and IAP.
| And ad serving will also probably stop working. So my
| opinion is: no. You can't distribute LGPL libraries in
| iOS apps.
| simiones wrote:
| > There's a phrase he uses that makes it clear to me what
| its intent is, "right to repair."
|
| The intent of the (author of the) LGPL and the letter of
| the LGPL (+ applicable law) may well be different. That
| is, just because the LGPL itself was designed to help
| with right to repair, doesn't mean it is successful at
| that job. It's also not necessarily the intention of
| others who use the LGPL - just like Linus Torvalds'
| intentions for using the GPLv2 are different from RMS's
| intentions in writing the GPL (hence why Linux is not
| migrating to GPLv3).
|
| My contention is that a license can't be invalidated by a
| 3rd party not giving you the technical means of
| exercising a right that you are granted. Similarly to how
| the GPLv2 couldn't stop TiVo from not allowing you to run
| their proprietary software if you modified the version of
| Linux they gave you, even if RMS intended it to.
| error503 wrote:
| > My contention is that a license can't be invalidated by
| a 3rd party not giving you the technical means of
| exercising a right that you are granted. Similarly to how
| the GPLv2 couldn't stop TiVo from not allowing you to run
| their proprietary software if you modified the version of
| Linux they gave you, even if RMS intended it to.
|
| What a way to twist things around. Apple (or the app
| developer, who chooses Apple to distribute their
| software) doesn't have the right to distribute the code
| _without_ abiding by the terms of the license. Copyright
| applies by default _unless_ those terms are met.
|
| TiVo's code wasn't subject to the GPL, so obviously they
| can have it do whatever they want, it's not remotely
| analogous to distributing copyrighted works outside the
| terms of the license that is the only thing allowing you
| to distribute them at all.
|
| Cryptographic controls might be an end-run around this
| (as they are being abused for many other anti-consumer
| purposes today). The license tries to account for this,
| but it looks like it only applies if the code is included
| _with_ the device. Unfortunately. The law really needs to
| catch up with this, it 's clearly a hack and not
| respecting the intent of this or other areas of law such
| as first-sale doctrine.
| kelnos wrote:
| Not to mention that in order to have that "development
| enrolled device", you need to first pay Apple a fee and
| get their permission. Seems to me that would count as an
| "extra restriction" added on top of the LGPL, which the
| license does not allow.
| microtherion wrote:
| libiconv ships with iOS, so Unity does not need to
| distribute it, only link to it. And according to the
| macOS man page, this is the BSD version.
| gumby wrote:
| The original was used, IIRC to license glibc when Steve
| Chamberlain and I (mainly him I'm pretty sure) were starting
| out on it -- I think that was the motivation. You're right:
| I'm not sure we actually shipped a glibc with that version.
|
| This was long before we hired Drepper.
| ffgjgf1 wrote:
| > But is that Unity's problem?
|
| Well:
|
| 1. Unity itself is using plenty of LGPL libraries itself so the
| same concerns apply.
|
| 2. If this is not an issue on desktop platforms where you can
| comply with LGPL there is nothing wrong with allowing such
| packages on the Asset Store. Certainly not all developers ship
| their Unity games on most platforms so it should be up to them
| to figure whether the specific package they decide to include
| can be used for a given platform.
| jillesvangurp wrote:
| Using open source development tools is fine. What matters is
| what you distribute to end users (i.e. the output of those
| tools). I think the issue with unity is that VLC ends up
| being distributed as part of unity applications.
|
| I'm not a lawyer but this might indeed have some valid issues
| associated with it depending on how this is done. So, I can
| see an argument for Unity simply not wanting to put their
| customers in a situation where they have to worry about these
| issues. It seems a bit drastic though given how useful it is.
|
| Banning companies/accounts seems like it's simply
| unprofessional/rude and unnecessary. Sounds like they need to
| have a conversation with whomever thought that was a good
| idea about professional conduct.
| ffgjgf1 wrote:
| > Using open source development tools is fine
|
| Yea but the article is claiming that Unity is including
| LGPL libraries in apps built with Unity, not just the
| editor itself.
| freedomben wrote:
| > _When I originally wrote the LGPL_
|
| This might be the best opening line of a HN comment I've ever
| seen :-D
|
| Don't feel obligated to respond, but how do you feel about the
| LGPL now? How do you feel about it's evolution given the way
| the world has changed? Would you do anything differently now?
| mort96 wrote:
| This comment section is so interesting. It's a great example of
| the value of PR; that it's not what you do that's important, but
| how you frame it.
|
| How VLC _should_ have framed this post:
|
| 1. Our plug-in got banned from the Unity Store for what we
| believe are bad reasons. Other high-profile plug-ins with LGPL
| code are still there.
|
| 2. To ensure that our users can still get our plug-in, we set up
| our own store which sells the plug-in.
|
| 3. Also the store has all these other services you can buy.
|
| But they omitted the second part. And the simple act of not
| explicitly connecting the store to the plug-in ban through enough
| PR speak seems to have been enough to make people here
| characterize this blog post as simply an ad for their store.
| martz wrote:
| You are correct, I should have framed it this way. I've edited
| the post. Thanks.
| polski-g wrote:
| Their plugin wasn't banned, their entire account was banned.
| sushi_dragon wrote:
| ff
| cupofjoakim wrote:
| Not a video game developer - but I wonder if it'd be a good call
| for videolan to make a vlc plugin for godot? It's still gaining
| momentum and (afaik, could be wrong) have the same thing as unity
| with a inbuilt media stack but it's fairly limited.
| eterevsky wrote:
| It sounds like this article tells only part of the story. Why
| would Unity ban VLC? I wonder if they have given any official
| comments about this.
| nightowl_games wrote:
| How does unity itself comply with the LGPL if it uses LGPL code?
|
| The blog post also says all games made with Unity depend on LGPL
| code. How do they comply?
|
| I'm so glad I generally don't have to think about this kind of
| stuff day to day.
| larodi wrote:
| Software business ha never been too polite to competition.
| yard2010 wrote:
| Fuck unity. Every time people have fun some aspiring jerk with an
| MBA comes to ruin the party for everyone involved.
| stackedinserter wrote:
| It's not an MBA jerk, it's just party grows in size and becomes
| visible to the judicial system, therefore susceptible to adult
| problems such as lawsuits from FSF.
| KomoD wrote:
| > Unity basically told us we were not welcome back to their
| Store, ever. Even if we were to remove all LGPL code from the
| Unity package.
|
| Why not include screenshots of these emails too?
| sylware wrote:
| There is no issue with the LGPL. The lesser GPL does not
| propagate to the whole.
|
| weird.
| nojvek wrote:
| App stores (or generally moderation) is a complex thing to get
| right.
|
| Once you have humans in the loop, you have bias. Not even humans
| can follow the set ambiguous guidelines and the appeals process
| is mostly broken.
|
| AI can somewhat help but language models are just that - language
| models - they don't have any deep understanding.
|
| Fundamentally I believe moderation will always be broken until we
| get algorithms capable of understanding the deeper meaning of
| things and apply them uniformly.
| chrismorgan wrote:
| > _The packages "VLC for Unity (Android)", "VLC for Unity (UWP)",
| "VLC for Unity (Windows)" have been deprecated._
|
| This is not deprecation. This is removal and banning.
| zackmorris wrote:
| It might be time for a mutually-assured destruction lobby/guild.
|
| In this case, when a company like Unity bans this VLC project for
| using LGPL software, the guild would open individual lawsuits
| against them to remove each of the other projects using LGPL
| code, based on various legal precedents around discrimination.
| Which would make it untenable to single out projects like this.
|
| This is a negative or low-vibration idea, I realize. Which is
| actually my point. If a policy causes one to go down these
| anger/fear/ego-based rabbit holes, then something is suspect with
| it. This is the litmus test I use.
|
| Somewhere along the way, we lost the wisdom or will to understand
| the difference between the letter of the law and the spirit of
| the law. And we sold our souls when we allowed wealth and power
| to override our discernment of right and wrong.
|
| If Unity wants to step into its power, it can start by abandoning
| knee-jerk policies designed to protect itself from liability
| against stupid laws. It can start saving a war chest to go to bat
| against patent/copyright/trademark trolls for the rest of us and
| protect the projects within its ecosystem instead of throwing its
| contributors under the bus. It can set an example for other large
| companies to follow so that we can eventually reform the system.
|
| But whatever all this malarky is has got to stop.
|
| I really want to like Unity for how it aligns with my goals as a
| shareware game developer in my formative years and a lot of other
| reasons, but they make it very hard to do so.
| flkenosad wrote:
| > This is a negative or low-vibration idea, I realize. Which is
| actually my point. If a policy causes one to go down these
| anger/fear/ego-based rabbit holes, then something is suspect
| with it. This is the litmus test I use.
|
| This is brilliant.
| cmeacham98 wrote:
| > based on various legal precedents around discrimination.
| Which would make it untenable to single out projects like this
|
| What precedents are those? Can you link or name the cases? I've
| never heard of such legal theory.
___________________________________________________________________
(page generated 2024-01-12 23:01 UTC)