|
| woofie11 wrote:
| I think the FSF is starting to realize that Stallman is not
| forever, and FSF ethics aren't forever. Having the FSF have
| exclusive rights to change license terms with "or newer" terms
| and to hold copyrights to projects is a bad idea as the founders
| of the FSF are getting older.
|
| I trust the FSF, but I have no idea who the FSF will be in
| another 20 years.
| pjmlp wrote:
| Actually everything GNU and Linux related.
|
| I am quite certain that when the generations that made this
| happen are gone, computer world will be back at business as
| usual like it was in the shareware days.
| [deleted]
| anthk wrote:
| Shareware days are dead.
|
| Also, there are diehard Libre GNU/Linux out there beside
| Stallman behind several projects.
| ghaff wrote:
| "Or newer" terms seem like a not so great idea generally. They
| seem to presuppose wise benevolence on the part of whoever
| controls the license.
| young_unixer wrote:
| Or if their website gets hacked, the hackers could publish a
| GPLv4.
| Wowfunhappy wrote:
| If it was merely someone impersonating the FSF, it wouldn't
| have legal weight. It might cause some confusion for (at
| most) a few days, but nothing more.
| orra wrote:
| lol, not really. You're thinking too literally, as we
| programmers often do. In this case, that's not how the law
| works.
| Wowfunhappy wrote:
| But without that bit, how do you avoid getting into a license
| incompatibility quagmire? You can't relicense a large OSS
| project without tracking down every individual contributor,
| which is frequently virtually impossible.
| segfaultbuserr wrote:
| > _They seem to presuppose wise benevolence on the part of
| whoever controls the license._
|
| I don't have a big problem with the _and newer_ term. Let 's
| imagine three possible scenarios. _Note: Copyright assignment
| is different from an "and newer" clause and it's not the
| subject of this comment._
|
| 1. _The new license is more restrictive_ , e.g. the FSF went
| full evil, GPL became an "All Rights Reserved" proprietary
| license. Outcome: everyone will just keep using the current
| version without an upgrade.
|
| 2. _The new license is more pessimistic_ , e.g. the FSF went
| full pessimistic, GPL became a BSD or a public domain
| license. Commentary: Doing so will not create direct harms to
| the existing users. Since the software remains free, I'll
| simply keep using it. And speaking as a developer, in the
| very unlikely scenario that the FSF decided to end copyleft,
| chances are, I'd likely to agree. However, a dogmatic
| copyleft advocate may point out that it's a potential
| vulnerability.
|
| 3. _The new license is similar_ , e.g. GPLv2 to GPLv3. This
| is the intended outcome.
|
| There are some reasonable objections, but I don't see it as a
| big threat, so I have no problem with it.
| michaelt wrote:
| Some would say the spirit of GPLv2 is "I give you this
| source code, in exchange you give back your changes"
|
| But if an evil version of the GPL comes out and someone
| forks your code and relicenses to it, you can no longer
| merge their changes.
| Gaelan wrote:
| For what its worth, the GPL (both 2 and 3) says this:
|
| > The Free Software Foundation may publish revised and/or new
| versions of the General Public License from time to time.
| Such new versions will be similar in spirit to the present
| version, but may differ in detail to address new problems or
| concerns.
|
| > Each version is given a distinguishing version number. If
| the Program specifies a version number of this License which
| applies to it and "any later version", you have the option of
| following the terms and conditions either of that version or
| of any later version published by the Free Software
| Foundation. If the Program does not specify a version number
| of this License, you may choose any version ever published by
| the Free Software Foundation.
|
| (The GPLv3 goes on to support some stuff about naming a
| "proxy" to approve new versions in addition to the FSF.)
|
| I'm no lawyer, but I imagine that would prevent glaringly-
| evil GPLv4 from being upgradable-to.
| xxpor wrote:
| Calling v3 "similar in spirit" seems like a stretch. I
| suppose that's literally true, but what they changed was
| significant enough that it drove a lot of projects away.
| belorn wrote:
| v3 prevented people from using patent agreements and
| hardware restrictions as additional restrictions on top
| of copyright law. They did drove away people who consider
| such additional restrictions to be beyond the scope of
| what a copyright license should be able to address. Linus
| for example have explained in depth how he consider the
| restrictions of patents and DRM to be bad and
| counterproductive to the community, but that he doesn't
| think a copyright license is the right place to address
| them.
|
| If a copyright license is the right or wrong place to
| address restrictions outside copyright law is an
| interesting discussion to have, but "similar in spirit"
| seems to match pretty well. I for one do not care if the
| legal restrictions sit under regular copyright law,
| software patent law, or Digital Millennium Copyright Act
| subsection DRM. They are pretty much similar in spirit.
| Gaelan wrote:
| Also, GPLv3 allows linking to AGPLv3 code; the AGPLv3, in
| the eyes of some, is a EULA.
| codewiz wrote:
| This decision came from the GCC Steering Committee, which has
| nothing to do with the FSF.
|
| The history of GCC includes a dark period in which version
| control wasn't public, and the project was dumping release
| tarballs on the GNU ftp server. Then, Cygnus Solutions started
| the Experimental GNU Compiler Suite (EGCS), a fork with a much
| more open development model, capable of attracting
| contributions from the whole Linux and embedded industry.
| Within a few years, many Linux distros had switched to EGCS,
| including Red Hat.
|
| If I remember correctly, talks of reconciliation started after
| Red Hat acquired Cygnus: other distros were worried that their
| competitor had gained too much control over a critical
| component of the OS. Eventually, the GNU developers and the
| EGCS contributors agreed to merge back under the GNU flag, but
| keeping EGCS's open development model.
|
| Nowadays, the GCC project is still hosted on the Red Hat-owned
| Sourceware servers, and its governance body is a technical
| board of contributors with various industry affiliations:
| https://gcc.gnu.org/steering.html
|
| TL;DR: the FSF and the GNU project no longer have much
| influence on GCC's direction.
| not2b wrote:
| Not that simple: EGCS was deliberately structured so that
| Cygnus would not control it; it involved many GCC developers
| who didn't work for them. The original EGCS steering
| committee had a non-Cygnus majority. From the very beginning,
| it was structured in such a way that it could become the
| official GCC once reality set in. This had nothing to do with
| Cygnus being acquired.
|
| There wasn't a working Linux libstdc++ from the FSF that
| anyone could build until EGCS fixed it; no Linux distros that
| supported C++ ever used an FSF version. They had to use weird
| hacks built by HJ Lu.
| sitkack wrote:
| I have vague memories of this time period. It seemed like
| GCC had stagnated and development wasn't being done in
| public. Many of the same gripes about extensibility and
| velocity that spawned the creation of clang/llvm.
|
| please no license fights.
| marcodiego wrote:
| The only GNU project I directly contributed code to was GNU nano.
| I was probably only willing to do so because it did not require
| anything like a CLA. But, if this didn't need any bureaucracy,
| I'd be glad to do so. I personally trust the FSF. Every new
| version of the GPL came after players tried to circumvent it so,
| having new updated versions of the GPL prevents players from
| abusing the right they have when new (legal) holes are
| discovered. AFAICS, the only institution I'd trust to assign my
| copyrights to is the FSF. They have proved time and time again to
| not sacrifice freedom and privacy in the name of profit or
| convenience.
| deng wrote:
| This is a good example of how to not steer a FOSS project.
| Seriously, what was the steering committee thinking? I mean, I
| tend to agree with this decision, but do they honestly believe
| that just announcing such a big change without any public
| discussion beforehand is going to fly?
| knz_ wrote:
| Well, this is a problem that FSF created. They tried to
| unilaterally appoint RMS to the steering committee and were
| forced to renege when most of GCC's top contributors threatened
| to walk away from the project.
|
| If they didn't get rid of the copyright aggreement there would
| have just been a fork or those people would have gone to work
| on other projects.
| deng wrote:
| Again: I tend to agree with this decision, but that's not the
| way to do this.
| knz_ wrote:
| There isn't any other way to do it. FSF showed their hand
| and lost.
| deng wrote:
| > There isn't any other way to do it.
|
| You cannot discuss things like this beforehand? You
| cannot do an RFD in the mailing list to gather feedback
| and questions? Even the announcement is sloppily written,
| because it sounds like gcc will now be licensed under
| GPLv3 exclusively (and not GPLv3+). This was later
| corrected in the thread, but confusion like this could
| have easily been avoided.
| freeone3000 wrote:
| This doesn't change anything for anybody except the copyright
| holder (who, if you've signed a copyright assignment statement,
| is not you). They're allowing contributors to maintain
| copyright over code submitted to GNU projects, and if you want
| to assign copyright to the FSF, you still can. The COS (a form
| of CLA) still grants the FSF the right to redistribute the code
| under GPLv3, so it doesn't affect users, either. I don't really
| know what a public consultation would have done here.
| deng wrote:
| Just follow the thread in the gcc mailing list. There are
| loads of questions now which need to be answered, just to
| name a few:
|
| - Can the steering committee make that decision?
|
| - Can the code be still easily(!) re-licensed to a possible
| GPLv4?
|
| - How can code later be re-licensed to GPL with runtime
| library exception or to LGPL?
|
| - Who should be named as copyright holder?
|
| It might very well be that all these questions can be easily
| answered, but that should have happened before.
| mikece wrote:
| Given three plus decades of FOSS experience, are the fears of
| permissive licenses like MIT and BSD (that companies will take,
| fork, and not give back in a meaningful way which will kill open
| source) considered to be well-founded? Could Linux not be as
| pervasive and important as it is today had it been released under
| a BSD license?
| Wxc2jjJmST9XWWL wrote:
| You're talking about a completely different thing here though
| than the article is about, and obviously we can only speculate.
|
| Linus' opinion always was: "I give you source code, you give me
| your changes back, we're even."[1] That's his summary of GPLv2
| and I think such an attitude is reasonable, and it might have
| certainly aided the Linux kernel development over time (almost
| sure of it).
|
| He disliked the GPLv3 exactly because of that. Because in his
| opinion it's (paraphrased) "I give you the source code, and now
| I dictate to you how you are allowed to use it." (see same
| link).
|
| Whether a BSD/MIT license hurts or helps a project is pure
| speculation. More permissive licenses might make code reuse
| more attractive, and be considered "more free" regarding code
| reuse. As to what code contributions you miss out on? Hard to
| judge. There definitely are companies building products
| utilizing FreeBSD / OpenBSD without committing all their
| changes back (or none to begin with).
|
| Pick the right license for your project. You don't care and are
| happy if someone uses it? Use a permissive license (MIT/ISC).
| You want to develop the product, improve on it, and want the
| changes back? Use something like GPLv2. You deeply care about
| your code running on open devices? Use GPLv3.
|
| There's no "one obvious right way" as far as I am concerned.
|
| [1] https://youtu.be/5PmHRSeA2c8?t=2840 _(from there to 56:51
| it 's about open source licenses)_
| pjmlp wrote:
| One example are the some of the stuff BSDs and clang miss out
| from Apple, Sony and Nintendo, as they don't upstream
| everything.
| [deleted]
| kryptiskt wrote:
| GPL doesn't require upstreaming, only that it's available.
| Lots of hardware companies don't want their code in the
| mainline kernel and make no effort to make it fit in. There
| are huge masses of Linux kernel code out there that can't
| be upstreamed because the kernel developers wouldn't touch
| it with a ten-foot pole.
| heavyset_go wrote:
| > _GPL doesn 't require upstreaming, only that it's
| available._
|
| While the GPL doesn't require upstreaming, it does
| require that derivative works that are distributed to
| users must make sources available. If those sources are
| available, then users or project maintainers can choose
| to upstream those changes if they want to.
|
| Apple, Sony, Nintendo etc don't make those source changes
| available despite distributing derivative works to users,
| so users and project maintainers can't upstream changes
| even if they wanted to.
| nix23 wrote:
| >GPL doesn't require upstreaming, only that it's
| available.
|
| That's not correct, you just have to make it available IF
| you redistribute the code. That's why you will never see
| a Google Data-center Linux-Kernel.
| bombcar wrote:
| The poster is making the distinction between working to
| merge your changes upstream and just dumping your changes
| on an unsuspecting world.
|
| The latter occurs decently often in the Linux Kernel
| world, and if there isn't much desire for the changes
| they can technically exist but never get merged.
|
| Whereas there are other drivers where the only one that
| cares about them is the company that uses them, but their
| developers have worked to get it actually upstreamed and
| help maintain it.
| nix23 wrote:
| Clang/LLVM was created by apple, and Netflix upstream's to
| FreeBSD...but google and microsoft to linux? And no don't
| tell me Microsoft works on linux, they try to integrate it
| into the windows "ecosystem".
| virtue3 wrote:
| Your viewpoint of microsoft and linux is about 10+ years
| out of date:
|
| https://www.techrepublic.com/article/what-is-microsoft-
| doing...
| pjmlp wrote:
| It was created, but now it is good enough for their
| Objective-C/Swift/MSL purposes, to the point everyone's
| wondering why clang is so behind in C++20 support.
| fooker wrote:
| >everyone's wondering why clang is so behind in C++20
| support
|
| This is wrong.
| https://en.cppreference.com/w/cpp/compiler_support
| pjmlp wrote:
| Count the number of red squares in GCC and MSVC++ versus
| clang.
| kergonath wrote:
| "It has more red boxes" is not equivalent to "everyone
| wonders why it's behind", which is clearly hyperbole.
| pjmlp wrote:
| I advise you to spend some time on /r/cpp.
|
| Then you'll see where people are wondering.
|
| Want to use modules on clang? Wait at least another year
| more.
|
| No wonder that Red-Hat is hiring for clang devs,
| alongside the contributions they already do for GCC.
| niea_11 wrote:
| Clang was created by Apple, LLVM wasn't.
|
| From wikipedia:
|
| _The LLVM project started in 2000 at the University of
| Illinois at Urbana-Champaign, under the direction of
| Vikram Adve and Chris Lattner. LLVM was originally
| developed as a research infrastructure to investigate
| dynamic compilation techniques for static and dynamic
| programming languages. LLVM was released under the
| University of Illinois /NCSA Open Source License, a
| permissive free software licence. In 2005, Apple Inc.
| hired Lattner and formed a team to work on the LLVM
| system for various uses within Apple's development
| systems. LLVM is an integral part of Apple's latest
| development tools for macOS and iOS._
|
| _Apple chose to develop a new compiler front end from
| scratch, supporting C, Objective-C and C++. This "clang"
| project was open-sourced in July 2007._
|
| https://en.wikipedia.org/wiki/LLVM#History
|
| https://en.wikipedia.org/wiki/Clang
| prionassembly wrote:
| I don't know exactly why, but this didn't happen with shrink
| wrapped software (eg OS X) and def happened massively with the
| cloud.
| kmeisthax wrote:
| Yes and no.
|
| Apple is perfectly willing to maintain, say, Swift and LLVM as
| Free projects; but they also have a proprietary fork with extra
| bits exclusive to their own hardware. For example, their
| proprietary GPU drivers compile shaders with it. LLVM being
| permissively licensed and owned by them means they have no
| reason to release those bits.
|
| This is not a hypothetical problem; it causes real harm to
| downstream users of LLVM. Rust has to support the current
| version of Apple's LLVM fork as well as the LLVM they ship with
| specifically just so you can compile watchOS apps, since that
| platform requires a proprietary bitcode format Apple never
| documented and only supports in their proprietary fork.
|
| Had Apple stuck with GCC they wouldn't have the legal ability
| to do this. Even if they had used GPL on LLVM, that license
| alone means that any contributions they take would also bind
| Apple to the same license. That's why people are extremely
| apprehensive about CLAs, because they're basically one-sided.
| The project vendor is free to sell exceptions or maintain
| proprietary forks, but you still have to comply with GPL.
| twic wrote:
| Even if Apple had basd their watchOS toolchain on GCC, and
| had published the source code for it, it is quite likely that
| their fork would have remained separate to upstream: upstream
| might not care about watchOS support, and Apple's fork might
| be based on an old version of GCC. In that case, Rust would
| still have to support two versions.
| stephenr wrote:
| As Apple own it anyway, what difference would releasing it as
| gpl make?
|
| They could still do as they like, as it's theirs. Do they
| accept significant code from the community?
|
| This is why I find the "use agpl" claims about projects run
| by a company disingenuous- they're using the licence
| restriction to prevent competition while they have the
| freedom to offer "enterprise" editions however they wish.
| kmeisthax wrote:
| Apple licenses their software as Apache 2 so a CLA isn't
| necessary, _everyone_ is free to make proprietary forks.
|
| Companies that want to release software as GPL but also
| sell exceptions or make forks either cannot accept third-
| party contributions (as then they'd be bound by the
| contributor's derivative copyright interest in the code) or
| have to require contributors sign CLAs.
|
| Projects with distributed copyright interest and a copyleft
| license governing all of that, like the Linux kernel,
| practically _cannot_ relicense or sell exceptions. _That
| 's_ the power of the GPL: everyone has to contribute on a
| level playing field.
| stephenr wrote:
| You're missing the question I asked though. Does Apple
| accept significant code contributions from outside the
| project?
|
| Because if they don't, the gpl wouldn't help.
|
| But regardless of that - I think this is the perfect
| example of the copyleft crowd not understanding the
| concept of compromise.
|
| Apple creates something, releases it as open source but
| also maintains some private extensions, and the response
| is: well why didn't you give it all to us?
| Gaelan wrote:
| > proprietary bitcode format Apple never documented and only
| supports in their proprietary fork
|
| IIRC, the bitcode format isn't proprietary--it's part of the
| open-source LLVM. The only issue is that it's not a stable
| format, so they need to use Apple's LLVM version and not an
| earlier or later open-source one.
| saagarjha wrote:
| Note that there is lowercase-b bitcode, which is part of
| LLVM, and uppercase-B Bitcode, which is Apple's thing built
| on top.
| rodgerd wrote:
| > Had Apple stuck with GCC they wouldn't have the legal
| ability to do this.
|
| They tried. rms lost the email.
| [deleted]
| mcguire wrote:
| BSD Unix predates Linux by 10-15 years. Personal computer
| versions were roughly feature comparable around 1992 (when I
| made my "should I install Linux or 386BSD" decision; Linux had
| shared libraries, 386BSD didn't).
|
| I know how I'd answer your question.
| tzs wrote:
| A big advantage for Linux in the early 90s was better support
| for cheap hardware.
|
| FreeBSD back then did not want to install on my PC. First
| problem was that I had an IDE CD-ROM and they only supported
| SCSI CD-ROM.
|
| Second problem was that it would not install in the
| unpartitioned space on my DOS/Windows SCSI hard disk.
|
| Linux supported IDE CD-ROM and could install on the same disk
| as DOS/Windows.
|
| Result: I installed Linux, and have used Linux ever since
| then when I need a free Unix-like system.
|
| According to their forums, there was no IDE support because
| nobody would seriously have IDE on a server. At the time you
| could make a reasonable case for that for hard disks, but not
| for CD-ROM (especially since IDE CD-ROMs were around $100 and
| SCSI CD-ROMs were around $400).
|
| The disk sharing limit was because they didn't think you
| could reliable infer the cylinder/head/sector (CHS) to
| logical black address (LBA) mapping that the other operating
| system(s) on the disk used. (The standard PC partition map at
| the time specified everything using CHS addressing, but disk
| interfaced had moved on the LBA addressing. Someone had to
| make up a pretend geometry for the disk, and then everyone
| had to consistently use that mapping to convert between CHS
| and LBA).
|
| In theory, you probably could find a legal partition setup
| with free space that was unsafe for another OS to use due to
| ambiguity of the mapping, but in practice that did not
| happen.
| cesarb wrote:
| > Linux supported IDE CD-ROM and could install on the same
| disk as DOS/Windows.
|
| Linux went beyond "could install on the same disk as
| DOS/Windows". Linux could install on the same _filesystem_
| as DOS /Windows. No need to repartition, no need for
| unpartitioned space. If you later decided Linux was not to
| your liking, you could simply erase your Linux directory.
|
| Result: I installed Linux on my C: partition, choosing a
| distribution which came with UMSDOS support. Some time
| later, I noticed that I rarely booted into DOS/Windows
| anymore, so I moved everything from the D: partition to the
| C: partition, erased the D: partition, and reinstalled
| Linux on that free space (using ext2 instead of UMSDOS). I
| have used Linux ever since then.
| twic wrote:
| There was also the lawsuit around BSD [1] which was only
| settled in 1994. I remember that uncertainty about the
| legal status of BSD lingered for a few years after that. I
| think Linux picked up a lot of steam from users and
| developers who wanted a unix on their PCs and were scared
| to touch BSD.
|
| [1] https://en.wikipedia.org/wiki/UNIX_System_Laboratories,
| _Inc.....
| ajross wrote:
| I guess that depends on definitions of "pervasive and
| important" more than it does facts on the ground.
|
| To my eyes, the number of open source drivers (near zero)
| available for Apple hardware, developed to run on their BSD-
| licensed kernel, pretty much provides all the evidence I need.
|
| No, a BSD Linux would have long since disappeared behind the
| curtain of some tech giant or another, just like Mach did into
| NeXT/Apple.
| ghaff wrote:
| Though binary blobs are a thing, albeit a somewhat
| controversial thing.
|
| Assuming a BSD-licensed Linux is a fairly small step away
| from assuming that Linux didn't exist given the existence of
| various BSD Unix flavors. And most people I know feel fairly
| strongly that, in the absence of Linux, BSD Unix would have
| come to the forefront.
| Macha wrote:
| But would it have come to the forefront in the form of
| FreeBSD, or in the form of macOS or a similar system?
| ghaff wrote:
| Service providers were already using the BSDs in the dot-
| com buildup when Linux wasn't quite as far along.
|
| For anyone interested, here's a debate between Bryan
| Cantrill and Steven J. Vaughan-Nichols I recorded last
| year on the topic "If Linux didn't exist, would we have
| had to invent it?"
|
| https://grhpodcasts.s3.amazonaws.com/Cantrill_Nichols.mp3
| ipaddr wrote:
| Why do they feel that way? It is debatable they would have
| finished, gotten the same press vs one guy who did it and
| without requiring changes back development might not have
| been able to keep up.
| ghaff wrote:
| Linux largely won out over the BSDs for various reasons
| that may (or may not) have included the license. I
| personally think Linux would be roughly where it is even
| if it used a BSD license.
|
| And in the absence of Linux entirely, most people I know
| consider that one of the BSDs would have been rallied
| around because there was just too much market demand for
| an open source *nix operating system.
| blihp wrote:
| Yes, they are well-founded as has been shown time and again.
| But the article is about copyright assignment, not changing the
| license. The debate around copyright assignment is whether
| there's any need/benefit to have a single entity 'own' all
| contributions vs. the individual contributors retaining
| ownership. There are a couple of big downsides to copyright
| assignment in that there's a longer term risk that a malicious
| actor will gain influence on a given project and change the
| terms going forward which has a tendency to drive potential
| contributors away. This has happened with various partially-
| open source (dual license, open core etc. types of projects)
| projects over the years.
| pjmlp wrote:
| Not at all, everyone would keep taking their piece of the BSD
| pie and be done with it.
|
| In fact,I deeply believe had Microsoft been more serious about
| POSIX support on Windows NT and Linux wouldn't even had a
| chance.
|
| Fortunately for Linux, Windows NT/POSIX was only for fulfil a
| checkbox on government contracts.
| diegocg wrote:
| There has been a lot of talk lately about big cloud companies
| using open source projects and forking them privately. I think
| the principles of the FSF are becoming more and more relevant,
| not less.
|
| People considered the GPLv3 excessive. Now we see tivoization
| everywhere, and people cries because corporations are soooo
| evil. Well, maybe you should not use licences that let them do
| that. People who think the FSF is too idealistic are missing
| the point - the FSF is terribly realistic, it's the ones who
| don't care about software freedom who end up learning the hard
| way why the FSF exists.
| bombcar wrote:
| What we're seeing is not tivoization but instead clouding -
| you have to go to the Affero GPL to protect against that.
|
| But that's a separate fight than the original GPL fight, and
| not necessarily one that really should be fought with the
| same fervor.
| [deleted]
| ufo wrote:
| Absolutely. In the context of GCC, there is the famous example
| of the Objective C frontend, which NeXT/Apple tried hard to
| make proprietary.
| wmf wrote:
| One thing I noticed is that early BSD developers almost all
| moved on to work on proprietary derivatives like SunOS, BSDi,
| NetApp, NeXT/MacOS, etc. Yet early Linux developers have kept
| contributing to Linux for decades, possibly because their
| expertise can't really be proprietized.
| ExcavateGrandMa wrote:
| I which this let ppl pushing pseudo (anonymous) commits...
|
| that make the diff :D
|
| & then appreciate the reviewers... :D
|
| Oh my!
| okprod wrote:
| I really hope GCC consulted with a lawyer before this
| natch wrote:
| Off topic but reminds me, I wonder if copyright assignment or
| trademark assignment (if it applies) would have helped freenode.
| In the sense of helping it stay as it was, a friendly place for
| users and project maintainers.
| marcodiego wrote:
| This may help contributors, but makes difficult to change the
| license in the future. I guess this the main reason why FSF
| requires copyright assignment to them. Now that this is no longer
| needed, I really hope that the world will not need anything newer
| than GPLv3.
| josephcsible wrote:
| This was addressed on the mailing list: changing to future
| versions of the GPL will still be possible, due to the "or any
| later version" wording. It's only changing to a non-GPL license
| that will now be impossible.
| Kenji wrote:
| Isn't the "or any later version" clause super dangerous? What
| if a party somehow takes over the FSF and publishes a GPLv4
| which is completely permissive? This seems like a time bomb.
| Am I misunderstanding something?
| segfaultbuserr wrote:
| > _makes difficult to change the license in the future_
|
| Copyright assignment is certainly a flexible way of doing that.
| But, if all you want is to upgrade GPL, it's completely
| unnecessary. As most GNU projects are licensed under the "with
| newer" clause, everyone, including GNU, can redistribute it
| under a new license unilaterally, without a copyright
| assignment - which, I suspect, makes a good argument to stop
| the copyright assignment requirement.
|
| Another important argument for copyright assignment is to allow
| centralized GPL enforcement. If a bad faith actor appears, the
| project can make the strongest legal defense. In my opinion the
| whole system works to enable this, e.g. the FSF also requires
| you to get the copyright disclaimer from your employers,
| otherwise the strength of the legal defense will be weaker.
|
| Unfortunately, for multiple reasons, a huge enforcement action
| is an extremely rare occurrence (the last, and possibly the
| only one, was the Cisco WRT54G case), and allegedly, some
| projects like the Linux kernel are even against active
| enforcements due to conflict of interest, thus, although I
| support active GPL enforcement in principle, based on the
| historical records I cannot say copyright assignment is all
| that useful (although I wish it would be). Moreover, the
| license enforcement model by the Software Freedom Conservatory
| showed centralized enforcement without copyright assignment
| appears practical [0] - all of these, I suspect, also make a
| good argument to stop the copyright assignment requirement.
|
| [0] https://sfconservancy.org/copyleft-compliance/enforcement-
| st...
| ksec wrote:
| I am wondering, what if somehow, hypothetically speaking, GPL
| 4.0 is the same as MIT or BSD.
|
| Does it mean it could "upgrade" to GPL 4.0 as well?
| CJefferson wrote:
| I wonder if this is largely a practical issue -- I've seen people
| waiting over a year for everything to get sorted out ( for
| example https://gcc.gnu.org/pipermail/gcc/2021-April/235288.html
| ), that's just not reasonable.
| invokestatic wrote:
| I'm somewhat surprised to hear that many GNU projects have
| copyright-assignment policies in place. That seems to go against
| what I used to think the FSF was all about. But after watching
| videos of Linus on GPL v3, it seems that the FSF is all about
| exerting control, despite having "Freedom" in their name.
| Macha wrote:
| Given they use GPL-x-or-later licenses and are all the
| authority needed to designate something as GPL 4 or 3.1 or
| whatever, if they wanted to go evil to utilise their control
| they already could have.
|
| It's not like they're opposed on principal to new license
| versions to benefit specific projects either, e.g. GFDL 1.3 has
| the "Wikipedia can relicense to Creative Commons" exception
| invokestatic wrote:
| The key difference to me is the "or later" part. So even if
| the FSF releases an evil version 3.1 or whatever, everyone
| could just continue to use version 3 instead. Whereas if the
| FSF owns all of the intellectual property, they can relicense
| it in its entirety to strictly 3.1.
| ignoranceprior wrote:
| If the evil version 3.1 is more restrictive than previous
| versions, then you are right to say people could just
| ignore it. However, if evil version 3.1 is more permissive,
| for an extreme example say they changed it to a verbatim
| copy of WTFPL, then there would be nothing stopping people
| from creating a proprietary fork of the project, the very
| thing copyleft was designed to prevent.
| Macha wrote:
| There's nothing stopping the next release of an application
| that has historically been GPL 2 or later being released as
| GPL 3.1 only, however? They can't go back and take back the
| existing licenses to existing versions (the whole non-
| revocable term of the license) so other users can still
| give you those versions under those licenses even if the
| FSF decided they didn't want to themselves.
| monocasa wrote:
| I think you're on the right track, they just view
| protecting the FSF as something that needs to happen
| regardless, and it can therefore be relied on. Then if
| there's a horrible flaw with a previous GPL, they can at
| least force their projects to the new version.
| ARandomerDude wrote:
| I don't understand why your original comment was flagged. I
| went and watched one of the Q&A videos from Linus Torvalds
| you mentioned and it was very educational. Thanks for your
| comment, even though the HN comment cancellers hated it.
| globular-toast wrote:
| There are libertarians and anarchists who think that freedom is
| having no laws at all. But what happens when a huge chemical
| company starts dumping waste on your lawn? Who do you call?
| They are free to do what they want, aren't they?
|
| Individual liberties can only go so far. If we want freedom as
| a society it is necessary to restrict individual freedom at the
| point that it begins to affect the freedoms and rights of
| others. In practice that means, unfortunately, governments,
| police and armies are necessary.
|
| Permissive licences are idealistic. Copyleft/FSF-style licences
| are pragmatic.
| superjan wrote:
| I think your point is that copyleft creates extra value
| because those extending it are incentivized to contribute
| their extensions. But in the case of gcc as compared to llvm,
| permissive licensing looks to be at least as successful. An
| issue with copyleft that you need to commit to providing the
| source beforehand. If you are allowed to choose afterwards,
| you don't need to ask in advance, and it's easier to make the
| case that upstreaming your patches is in the organization's
| best interest.
|
| And yes I know copyleft only requires only providing code to
| your users, but in practice the organization assumes that
| means the distribution can't be enforced.
| msla wrote:
| The FSF is about protecting freedom, which includes being able
| to sue people who infringe on that freedom.
|
| A slogan without enforcement is toothless, and businesses only
| respect teeth.
| Wxc2jjJmST9XWWL wrote:
| To anyone wondering, pretty sure "Linus talking about GPLv3"
| here refers to Linus at Debconf in 2014
| https://youtu.be/5PmHRSeA2c8?t=2840 _(from there to 56:51 it 's
| about open source licenses)_
| duxup wrote:
| Thank you. That was helpful.
| nonfamous wrote:
| This is a good thing for the health of the GNU ecosystem, and I
| hope other GNU projects adopt this practice.
|
| Related story: a couple of years ago, the current maintainer of
| an Emacs package reached out to me. Apparently the FSF wanted to
| make it part of the official Emacs distribution, and wanted me to
| assign my copyright to them. I was happy to do so, BUT: the code
| was written more than 20 years ago when I was at university,
| which (according to the FSF) meant I needed to get a copyright
| release from the university, in a country I no longer lived in
| and that I had not interacted with for literal decades. This
| seemed like far too much trouble at that point, so I gave up, and
| the package never became part of Emacs.
| brnt wrote:
| Wouldnt the copyright have expired at that point?
| NavinF wrote:
| In a sane world it would have expired, but not here.
|
| cf. The Mickey Mouse Protection Act https://en.m.wikipedia.or
| g/wiki/Copyright_Term_Extension_Act...
| rodgerd wrote:
| Copyright is either the death of the author plus a period, or
| a length of time for a non-human entity such as a university
| or limited liability company.
| rwmj wrote:
| Copyright terms last effectively forever, and certainly a lot
| lot longer than 20 years.
| https://en.wikipedia.org/wiki/Copyright_term
| johnzim wrote:
| Copyright tends to run from the death of the author for a
| period (in the US is 70 years after death). As for where it's
| assigned to an institution, it'll still have a long time to
| run - decades!
| btilly wrote:
| Nobody is discussing the reason for the copyright-assignment
| requirement. I only know about it because I was caught in the
| issue that it means to prevent nearly 20 years ago.
|
| The issue is that in many places (for example New York State),
| work done by a professional employee actually belongs to your
| employer. A developer can write code, contribute it where they
| want, and license it as they wish. But the code is actually owned
| by their employer. Which means that if there is a future problem,
| the employer can assert their copyright interest and people who
| thought that they had the right to use that code, suddenly don't.
|
| Because developers themselves are seldom aware of such rules, the
| FSF took the ultra-safe approach of requiring employers to sign
| off. That way they are absolutely sure that there will never be a
| problem.
|
| However other open source projects have found that, in practice,
| problems are rare. And when there is a problem, the employers
| usually will agree to the license.
| daptaq wrote:
| AFAIK (one of the) the main reason for the copyright
| requirements is so that the GNU project can update the license,
| when a new version of the GPL is released, fixing loopholes or
| other issues in older versions. I am weary of dropping the
| copyright assignment, because issues like Tivoization could
| always pop up without anyone anticipating it, and even have
| contributors actively resisting the updates to fix these
| issues.
|
| (Edit: What I also came to think of is that GCC recently
| positioned itself in opposition to the FSF because of the
| "Stallman-Controversy". Is this a kind of retaliation on their
| part?)
| geenew wrote:
| s/weary/wary
| kop316 wrote:
| I figured that's why the GPL includes the language that says
| "GPL {x} or at your option a later version". That way, if you
| want to go to GPL {x+1}, the license already allows it.
| opk wrote:
| The GPL already includes a clause stating "or any later
| version" so GNU software can happily update the GPL version.
| Linux specifically has an exception to this. It is the
| dodgiest part of the whole GPL in my opinion and gives the
| Free Software Foundation a lot of power and makes it
| impossible to fork or replace the established organisation if
| it goes awry.
| carlhjerpe wrote:
| Doesn't this work out a bit like MongoDB, where Amazon
| forked a version released before they replaced the GPL with
| their own license? Meaning the freedoms of the GPL will be
| withheld, no?
| wahern wrote:
| Copyright assignment is about enforceability, not updating
| the license. It's much easier to maintain copyright
| registrations, and to prosecute an infringement case, when
| you control all the copyrights.
|
| Anyhow, we don't have to guess why they want it:
|
| > Under US copyright law, which is the law under which most
| free software programs have historically been first
| published, there are very substantial procedural advantages
| to registration of copyright. And despite the broad right of
| distribution conveyed by the GPL, enforcement of copyright is
| generally not possible for distributors: only the copyright
| holder or someone having assignment of the copyright can
| enforce the license. If there are multiple authors of a
| copyrighted work, successful enforcement depends on having
| the cooperation of all authors.
|
| > In order to make sure that all of our copyrights can meet
| the recordkeeping and other requirements of registration, and
| in order to be able to enforce the GPL most effectively, FSF
| requires that each author of code incorporated in FSF
| projects provide a copyright assignment, and, where
| appropriate, a disclaimer of any work-for-hire ownership
| claims by the programmer's employer. That way we can be sure
| that all the code in FSF projects is free code, whose freedom
| we can most effectively protect, and therefore on which other
| developers can completely rely.
|
| https://www.gnu.org/licenses/why-assign.en.html
| daptaq wrote:
| Yes, it is probably primarily about enforceability, but why
| should that mean that updating the license is also part of
| the consideration?
| wahern wrote:
| There could be all kinds of secondary motivations,
| including that ability. But most GPL'd software includes
| the "or later" provision, which means it's relatively
| easy for the FSF to update the license of projects,
| especially if they stipulate that contributions must be
| licensed thusly. Note that with or without assignment,
| the FSF could never rescind the license on previously
| released software, except perhaps for infringers (because
| of the termination clause). So assignment doesn't
| actually provide much value on that score except as it
| relates to enforcement.
| rodgerd wrote:
| > What I also came to think of is that GCC recently
| positioned itself in opposition to the FSF because of the
| "Stallman-Controversy". Is this a kind of retaliation on
| their part?
|
| "Random acts of rms" aren't a new problem for the GCC
| developers, and resulted in the egcs split, have caused
| ongoing pain with people trying to improve the ability of GCC
| to integrate with IDEs, and of course there's the whole
| debacle where the Clang developers offered their work to the
| FSF but Stallman missed the email and found it a decade
| later...
|
| However, several of the lead developers for C++ (at least)
| announced they were no longer going to be assigning their
| code ownership to the FSF in the wake of the recent FSF calls
| around rms, which has put the GCC project in the position
| where the have the choices to:
|
| 1. Hope the FSF change their mind and prioritise free
| software ahead of the Cult of Richard.
|
| 2. Commit to shipping a sub-par and increasingly irrelevant
| free software compiler.
|
| 3. Drop the CLA requirement.
|
| In the absence of any change on the first point, the third
| option looks like the best way to ensure that there is still
| a high-quality, GPL complier available.
| knz_ wrote:
| > (Edit: What I also came to think of is that GCC recently
| positioned itself in opposition to the FSF because of the
| "Stallman-Controversy". Is this a kind of retaliation on
| their part?)
|
| More like a necessity to keep the project alive. Half of the
| top contributors threatened to leave when FSF tried to coup
| the steering committee.
| kencausey wrote:
| If you can go into it, what was the resolution of the issue in
| which you were caught?
| notRobot wrote:
| Can someone please tl;dr why this was a requirement in the first
| place?
|
| I trust the FSF and it seems like a good idea, but I'm not sure
| why.
| gumby wrote:
| The concern is that in a legal dispute, the FSF might not have
| legal standing (I.e. in a lawsuit) if the code had been
| contributed by _and remained the property_ of someone else. And
| what if that person could not be found.
|
| I wrote the blanket assignment back in 1989 or 1990. I still
| consider this a legitimate risk.
| tobias3 wrote:
| One could see this in action in the Hellwig vs VMWare court
| case (one of the few GPL court cases).
|
| As a first step they had to show that Hellwig had made
| changes to code that VMWare uses that can be copyrighted.
| Especially difficult since every line in Linux is modified by
| a few different people. They failed at that and that ended
| the lawsuit if I remember correctly.
| dec0dedab0de wrote:
| This may not be the FSF stance, but I can think of 3 reasons.
|
| The main one is it is easier to change the license if you want
| to.
|
| IANAL so I'll probably mess up these next two, which I believe
| are more theoretical than anything in regard to software. At
| least in the US.
|
| It is possible for a copyright holder to revoke a license. so
| there could be an important contribution living in the code
| base and then one day the author could revoke the license and
| they would have to remove the code, and somehow prove their
| replacement was not infringing.
|
| There is a concept of Joint Authorship. Where it could be
| possible for a contributor to claim joint copyright over the
| entire project, and then release it on their own under any
| license they want. I could be wrong, but I believe it has
| happened where book editors that didn't have an air tight
| contract, were able to claim joint copyright over a book they
| edited, and release their own versions with a different
| publisher.
| mcguire wrote:
| " _It is possible for a copyright holder to revoke a license.
| so there could be an important contribution living in the
| code base and then one day the author could revoke the
| license and they would have to remove the code, and somehow
| prove their replacement was not infringing._ "
|
| I don't believe that is true. A license is a contract; there
| are only two ways to revoke a contract: if the contract is
| illegal or if the contract provides terms to let you revoke
| it. If you publish software under the GPL, there is no way to
| revoke the license.
|
| You could stop supporting the contribution in the code base
| and release alternate versions under different licenses, but
| the versions in the code base under the GPL remain available
| under the original terms.
| tzs wrote:
| Nonexclusive licenses granted without consideration are by
| default revocable. Fortunately, GPLv3 section 2 explicitly
| states that it is irrevocable.
|
| GPLv2 omits such language, so to make it irrevocable you
| are going to want to find consideration. You can probably
| whack it a few times with your promissory estoppel stick
| hard enough to get some consideration to bleed out of it.
|
| That's probably good enough to get irrevocability.
| Macha wrote:
| The third is specific laws having specific terms that
| supercede the contract, e.g. discharging contractually
| obligated repayments in personal bankruptcy
| ajross wrote:
| The copyright assignment policy dates from very early in GPL
| history, when it was broadly thought that in order to make
| copyleft work the FSF was going to have to sue entities that
| had misappropriated GPL software. Doing that is harder when you
| start from a position of having to prove that you even own the
| relevant copyright in the first place.
|
| It turns out this didn't happen. People who want to use free
| software and to stay legal just... honored the license. People
| who didn't want to do so used other software. And the only
| people who actually were breaking the license turned out to be
| tiny fly-by-night operations in parts of the world where
| copyright litigation wasn't a very useful tool anyway.
| nullc wrote:
| The GPL has been regularly violated by huge multi-billion
| dollar corporations.
|
| But the FSF has had a policy of favoring compliance and
| forgiveness over punishment, and they've aggressively avoided
| litigation-- instead preferring to negotiate for compliance
| with goodwill loss as the threat-- to the point of
| contributing to some splits in free software. E.g. this is a
| point of disagreement between SFC and FSF.
| bombcar wrote:
| Haven't a significant number of the multi-billion dollar
| violations turned out to be rather "oh we didn't know" as
| opposed to intentional malice?
| bluGill wrote:
| Compliance and forgiveness is probably the best policy
| anyway: courts will consider intentions. Companies that are
| sued for a violation and can tell the judge "look at the
| evidence: we have a history of doing the right thing and
| messed up in this one case" get a tiny slap and continue
| one. By having a reputation of make right and we won't sue
| companies have nothing to lose by making right. By having a
| history of suing they will win some cases, but many of them
| the total gained will be less than laywer fees because of
| all the companies that are able to say "we tried to make
| right but they rejected this reasonable offer".
|
| Also, what if a company decides to ignore the GPL and pay
| up? The courts and law understand monetary damages. The FSF
| runs the risk of the judge deciding that the code is
| already out there, and the value the code is $X: therefore
| the infringer should reasonably buy a license for $X and
| doesn't have to give source code back. This would violate
| the spirit of the GPL, but would fit the letter of the law.
| nullc wrote:
| I'm not disagreeing with the FSF's approach.
|
| But the fact that the FSF hasn't in fact litigated isn't
| by itself a reason that preserving the clear ability to
| litigate isn't useful. We don't know how many cases an
| infringer was made more likely to come into compliance by
| the fact that work had clear ownership, particularly
| because the FSF has avoided litigation when they had
| other avenues open.
| bluGill wrote:
| The FSF only needs some of the code to litigate though.
| It is better own everything, but that only is a factor
| after the case is done, if the FSF owns 20% of the code,
| then they get 20% of the total possible value of the
| infringement. (likely after lawyer fees, and class-action
| can apply)
|
| It is easier if they own all the code, but it isn't
| required.
| wahern wrote:
| > It is easier if they own all the code, but it isn't
| required.
|
| It's not that simple. For joint works any _single_ author
| can grant rights to the entire work. Do you know what the
| caselaw is regarding joint works as applied to typical
| FOSS projects? I don 't. But I suspect it's less than
| crystal clear (see, e.g., https://papers.ssrn.com/sol3/pa
| pers.cfm?abstract_id=2999185) and therefore creates
| significant risk when attempting enforcement. Litigation
| is costly, and a wrinkle like this could potentially be
| exploited by an infringer to drag out an enforcement case
| for many years.
| ajross wrote:
| What about arguments like "the code the FSF owns isn't
| what I infringed?", or "the FSF doesn't own the code
| because this other developer wrote this bit and isn't a
| party to the suit; let me call them as a witness"?
|
| I mean, it's true that you could still win a case having
| to win those arguments, but it's harder.
|
| Defense in depth isn't just a computer security
| technique. Any lawyer will tell you that the easiest
| argument to win is one that can't be brought in the first
| place.
| warp wrote:
| There doesn't seem to be any disagreement on GPL
| enforcement between SFC and FSF:
|
| - https://sfconservancy.org/copyleft-
| compliance/principles.htm...
|
| - https://www.fsf.org/licensing/enforcement-principles
| nullc wrote:
| They don't disagree on the general ideology, at least on
| paper, but when it comes to enforcement actions SFC is
| much more prone to litigate than the FSF.
|
| IIRC FSF has only sued _once_ , conservancy has like 100x
| the rate of lawsuits per years-existed. :P
| sigjuice wrote:
| https://www.gnu.org/licenses/why-assign.en.html
| jhonsrid wrote:
| This seems to imply copyright assignment to the FSF is
| _required_ for GNU projects? I wonder what RMS's take is on a
| unilateral change like this in one of the highest profile GNU
| projects?
| snackematician wrote:
| I really hope other GNU projects, in particular Emacs, follow
| suit, though I doubt it will happen.
|
| In my experience it is a massive hassle to get the copyright
| disclaimer from my employers. I'm currently on hold from
| contributing to Emacs because my paperwork is working its way
| through the legal bureuacracy of my new employer. Also, I have
| former coworkers from previous companies who were enthusiastic
| about Emacs, but unwilling to go through the trouble of getting
| the paperwork to contribute.
|
| I think getting this paperwork through is probably more difficult
| in my industry, than in others -- I do R&D at a large
| pharmaceutical.
|
| Still, I think the copyright disclaimer is one of the biggest
| factors that is limiting the number and diversity of Emacs
| contributors. I also think it's unnecessary, as Linux does not
| have this requirement, and it has successfully enforced the GPL,
| for example on router manufacturers.
| knorker wrote:
| GNU Radio did this recently. Now they just have a CLA, I think.
___________________________________________________________________
(page generated 2021-06-01 23:00 UTC) |