As someone who wants GPL enforcement, I still say don't sign a CLA, for two reasons:
- Centralizing copyright ownership in a single entity grants that entity the ability to lock down the project at any time and defeat the copyleft (e.g. Oracle killing off OpenSolaris). I consider this a worse outcome than a copyleft that is unenforced. It also encourages malicious enforcement (e.g. Oracle v. Google) that runs contrary to the goals of FOSS.
- Due to some very specific peculiarities of US law, regular users can sue companies that don't follow the GPL, because the source code disclosure requirement makes you a third-party beneficiary of the copyright license (which in US law is a contract).
The last one is a bit unfair to the article because the rulings in question happened after it was published. But it obviates the biggest benefit of centralized ownership - clear and unambiguous standing to sue. If things were the opposite - i.e. the courts said third-party beneficiaries can't sue and only owners can - then there would be an argument for keeping ownership of critical parts of the project in an entity with no conflict of interest against enforcement.
Even then, I don't see why ownership has to be centralized. Under US law, joint owners of a single copyrighted work both have standing to sue. Having more owners means more people with standing. In lieu of a classic CLA with a single point of failure, you could have a policy of accepting any code that is either owned by the developer itself (after their employment contracts have been vetted) or any of a number of trustworthy FOSS organizations who are committed to enforcing GPL. All parties would have standing to sue individually and could additionally sue as a class in a single action.
I think you may be overestimating the usefulness of a third-party beneficiary approach. There are two issues with it:
(1) Isn't SFC vs the only case where how third-party beneficiary law applies to GPL enforcement has come up? That case has not yet gone to trial. The third-party beneficiaries have only been considered in the context of motions of summary judgement. The court ruled that this will have to be determined at trial.
(2) You can only have a third-party beneficiary to a contract when there is a contract.
The defendant should be able to defeat a third-party beneficiary claim by saying that they did not agree to the license. They saw code they wanted to use and thought it was public domain or thought their use would be covered by fair use or decided that they would go ahead and infringe its copyright because they thought the risk of the copyright owners suing was negligible.
That approach would have some risks if the copyright owners later do sue, because it would be tantamount to admitting their infringement was willful which can greatly increase statutory damages.
> Centralizing copyright ownership in a single entity grants that entity the ability to lock down the project at any time and defeat the copyleft
It also grants the ability to make the project more open. I once wanted to change a project I was part of to a more permissive public domain license. Leadership was in favour but ultimately rejected it due the impracticality of dealing with getting agreement from everyone who had ever contributed (there were no CLAs). So it remained with the old license.
If an entity unilaterally changes the license, you can still fork it at the time the change was made and continue from there.
Now, I’m not defending Contributor License Agreements. I also dislike them and the hurdles they cause to contribution. Plus, the situation you described of the project becoming more locked down instead of less is likely more common, and forks can be a pain for everyone. Still, wanted to share the other side.
>Centralizing copyright ownership in a single entity grants that entity the ability to lock down the project at any time and defeat the copyleft (e.g. Oracle killing off OpenSolaris).
I don't understand how copyright ownership of FOSS code would impact an entity locking down the project. I don't think owning the copyright gives the entity the ability to do that. Maybe owning the trademark or the Github repo would, but not the copyright.
> Centralizing copyright ownership in a single entity grants that entity the ability to lock down the project at any time...
By this logic, as well as refusing to sign CLAs you should also refuse to adopt any MIT licensed or similar software, since that can also be "locked down".
My new rule is to never contribute and do my best to avoid using any free software that requires a CLA. Shared copyright ownership is very important to maintaining software freedoms. It makes it impossible for a single party to change the license in ways counter to the communities desires. There have been many recent examples of this sort of bad behavior that have driven this point home for me.
But then following this philosophy, shouldn't you favour copyleft licenses, too? Because if it's permissive, they can suddenly go proprietary without caring "much" about copyrights, right?
I have come to these rules:
- Never sign a CLA.
- In my projects, the "most permissive" licence I use is MPLv2 (which is weak copyleft). When I release OSS software, there is absolutely no point in using a permissive license: MPLv2 should be fine for everybody. Of course sometimes I like the GPL family, and recently I've come to like the EUPL.
You should consider signing one anyway depending on whether you like the creator. This gives the maintainer of the project a way to make money from his work: sublicensing it to companies under a different license. This promotes the use of extreme copyleft licenses like the AGPLv3.
I actually emailed Stallman to ask about the ethics of this. He replied that it's better for everyone when only the creator has this power. Permissive licenses give everyone else that power too. Copyleft licenses don't. Only the copyright owner can sublicense. Others must comply or pay for it.
> It is my understanding that as the copyright holders
> they have the right to do it without any problems.
> They leverage the AGPLv3 to make it harder for their
> competitors to use the code to compete against them.
I see what you mean. The original developer can engage
in a practice that blocks coopertation.
By contrast, using some other license, such as the ordinary GPL,
would permitt ANY user of the program to engage in that practice.
In a perverse sense that could seem more fair,
but I think it is also more harmful.
On balance, using the AGPL is better.
It also makes it impossible for a single (or multiple parties) to change the license in ways in line with the community's desire, including moving to more permissive licenses.
And I'm not really sure I get the risk here. Projects (Redis, Terraform) changed license, the community responded by forking, and the result is at worst more fragmentation. If a company doesn't think a project is worth maintaining without a more monetizable license having multiple code owners isn't going to force them to keep maintaining the software.
I'm not saying multiple owners doesn't have benefits, but it's far from clear enough to present a cut and dried policy like this I think.
Your rule is a common one, but somewhat misses the point of the argument. In the absence of a CLA who does own the copyright to the work you do?
The point of the article us that it may, or may not, be you.
I notice that you weren't clear on this part in your post, suggesting perhaps that it's not something that's front-of-mind like the CLA is.
On the CLA front I'm on the fence. Assign, don't assign, that's for each person to decide.
But the alternative to CLA is not necessarily "I keep the copyright". That's the point the article is asking you to consider.
Aside; unless you have a specific bit of paper assigning copyright to you, and assuming you have a day job, it's very unlikely that you hold the copyright even if you only do OSS work at home on weekends.
And lastly - have you ever enforced your copyright legally? If you have never enforced a copyright violation then your work is effectively public domain. Yes the threat that you could take action exists, but in practice your contributed-to-project can change their license and call your bluff.
> When you take a job, in most places in the world, by default, your employer owns and/or effectively controls all your copyrights.
Is this really true? I haven't checked my employment agreement, but I'm pretty sure that my employer only controls the copyrights for a) work I do for them, and b) any other side work I happen to do in my employer's field (which never happens).
AFAIK, work I do on my own that is unrelated to my employer belongs to me, and I've never had anyone from my job try to assert otherwise. (I have plenty of publicly-visible code on GitHub that they could glom onto if they wanted, although none of it is commercially important.)
---
Edit: My employee agreement says "I understand that the
provisions this Agreement requiring assignment of Company Work Product do not apply to any Non-Company Work Product that qualifies fully under the provisions of Section 2870 of the California Labor Code, or any similar state invention law."
That labor code says "Any provision in an employment agreement which provides that an employee shall assign, or offer to assign, any of his or her rights in an invention to his or her employer shall not apply to an invention that the
employee developed entirely on his or her own time without using the employer’s equipment, supplies, facilities, or trade secret information except for those inventions that either:
(1) Relate at the time of conception or reduction to practice of the invention to the employer’s business, or actual or demonstrably anticipated research or development of the employer; or
(2) Result from any work performed by the employee for the
employer."
The employment lawyer I consulted a few years back stated all work done outside office hours is essentially implicit property of your employer in Canada/UK... unless explicitly stated in your employment contract that external unrelated projects are your own.
In most of the US, all work done outside of your employers business is implicitly your own... unless explicitly stated in your employment contract that they have rights to such works.
In general, most commercial businesses won't care unless their IP or resources were misappropriated for a personal project. Best of luck =3
You should probably check it, in the UK this is pretty standard, and I believe it is in the US as well. I suspect most of Europe is similar as well. It will vary by company and industry, but in my experience when you ask HR and Legal to put together a contract for a knowledge-worker, this is a standard edition by them.
I've never had a job actually assert anything around this personally, but I do make sure to have anything notable signed off by my employer as "mine". That's assuming it's unrelated to my employers field of course.
I work at a fortune 500 and you have to go through hoops to own anything. By letter of the contract they own all the IP we produce which legally includes photos taken. Doubtful they'd enforce that, but it gives them a strong position if one were to write any useful code outside of work.
From my personal experience, this really depends. Some employment agreements are stated very widely, so the employer even gets retroactive ownership of things you do in the past; some include copyrights for work you'll do in the future, after employment, in the same domain which can be said to be based on work you've done for the employer; some include all side-work regardless of domain, while you work there; some don't.
Likewise, I have commercially irrelevant code on GitHub/Codeberg. But as it is all under BSD or MIT licenses, it makes no practical difference to me if my current employer wants to claim ownership; I can pick up where I left off all the same.
I’ve previously worked doing technology assessments in the M&A world and copyleft is a big deal there. I’ve had to comb through code (not always automatable) to find any copyleft code and then have had to sit through many meetings with lawyers trying to explain the risk and complexity involved. I’ve seen it tank entire acquisitions.
> The central thread here is collective action by principled people who will use copyleft primarily as a tool for rights of users and for the improvement of copylefted projects.
Joint stock companies are about hierarchy and control. Free software is very much not about that. Free software is a syndicalist movement by software developers. Software developers have taken control over computing infrastructure, we develop it on our own terms. We have settled on a decentralized model, which shares openly, without constraint.
People with the hierarchical mindset hate another party taking ownership because that’s something they don’t have control over. They would be happy to have you hunched over a keyboard desperately typing while they bark orders at you, regardless of whether or not that produces anything of value. Linux and GCC are both inspired products that grew in the cradle of copyleft, they are excellent because of their open development. Meanwhile, large corporations are happy silo themselves into unproductive morasses and play ritualistic political games [1].
Copyleft benefits users because it produces better software. Enforcement is the only card to play to make sure that continues. Unfortunately our reaction to licensing has been immature. When asked about licensing, we’re happy to throw up our hands and say “I don’t care about that” (see WTFPL) and carry on with development as if some helpful person from legal will do the legwork for us in exchange for our wonderful output. The fact is, legal is still in the 19th-century as far as intellectual property is concerned, and are happy to respond in a formal and threatening way to anything that challenges their hegemony. We have to work with our colleagues in the legal community, educate, and give them a place in our decentralized world. Otherwise, we’ll just be workers fighting for our slice of the pie in a rat race, commanded by people who are happy with consistent mediocrity. Users will suffer.
This is why I don't want to put any free testing into a copylefted copyright like Element, let alone code or docs contributions. I realize I'm testing Discord for free, but it's different with Element, because for years I perceived it as being a vendor-neutral open source project. The copyleft is so it isn't vendor neutral.
OTOH there are projects like Forgejo which are copyleft but are still vendor neutral. Even though it's vendor neutral, I wouldn't be too thrilled if it were AGPL, but it's just GPL. So I am still a happy Codeberg user. (Element is AGPL)
Zulip is my favorite open source chat now. It's used by some stuff that's relevant to me right now including Bytecode Alliance and Julia.
What's the deal with Element? Is it AGPL, but exclusively developed by one company? Or does it take contributions but with a CLA giving the copyright to the company? I'm not aware of the situation there.
Why is it not possible for FOSS authors (who hold copyrights and have not signed them away to their employers) to contract with NGOs like the Free Software Conservancy, allowing it to act on their behalf when it comes to enforcement? Do the copyrights really need to be transferred? I mean, people use lawyers, why can't they let the FSC act in a similar role and with similar powers of attorney?
That is possible, SFC member projects get that service, as well as Linux, Debian and probably other projects too. Copyright transfer isn't needed for that, there is the option of signing enforcement agreements instead.
Corporate ownership of open source copyrights is actually optimal from an efficiency standpoint. Companies have the resources and legal teams to properly steward these projects, while non-profits like the FSF are bogged down with bureaucracy and outdated ideological concerns.
The article vastly overstates the importance of enforcement. In practice, the collaborative nature of modern software development makes strict copyleft enforcement unnecessary and potentially harmful to innovation. Most companies comply voluntarily because it makes business sense.
I've worked at several major tech companies and have never once encountered the kind of enforcement issues described here. This seems like a solution in search of a problem.
For what I see in robotics, I can say that most products I see being shipped violate hundreds (thousands?) of licenses. Both permissive (which generally require attribution) and all kinds of copyleft.
Many IoT products use stuff like https://www.balena.io/os and essentially ship products that contain docker containers of all sorts. If you ship an Ubuntu container, you ship a ton of packages with it that have license requirements, right?
Nobody cares, nobody knows, nobody wanna know. That's the situation.
In general, Debian has been rather strict with what licenses it allows in its repositories.
The right to transfer copyrighted works may also open people to legal action from employers in some countries outside the US. i.e. the identical contract text can have two different meanings depending where it is signed.
I prefer to license most works as Apache 2.0, and this ensures people can do whatever they need to get the use-case solved in whatever legal obligation they are encumbered within.
Note, implicit personal copyright is always in effect... The original author(s) must explicitly state the work is public-domain/CC0, or you could be in violation.
From what I've seen over the years, there are a few groups of trouble makers:
1. Companies from countries that have zero software copyright/patent laws. So will cycle GPL works into the closed-source production pipeline in commercial settings. i.e. the culture views the US concept of owning ideas as absurd.
2. Folks that think linking against a LGPL shared object for compatibility reasons obligates developers divulge source-code. Note, there is source code released under several different licenses for legal compatibility reasons. i.e. the work may be fine with static linking under one version, and at the same time violate LGPL with the identical binary.
3. submarine attacks... malicious/foolish folks that distribute works they have zero legal right to re-license, re-publish, or possess. For Unity developers on US soil, the store is peppered with works still owned by Studios that can get you sued out of existence.
CC0 and Apache 2.0 are the safest options in my opinion, but one still must trust the authors aren't poisoning the chain of trust with copyright violations.
This is another reason why out-of-band package managers are dangerous to commercial entities. Microsoft will be in business for a long time yet... =3
If you don’t modify any of the source for the applications in those containers, then you have no changes to release. IANAL, but my understanding is that the GPL applies to a body of source code and not other things running alongside that source code. The distinctions are nuanced (Galoob v. Nintendo, etc.) but generally if you’re violating the GPL, you can kinda feel it.
Like, in Welte v. Sitecom, Sitecom didn’t just ship Welte’s work with their product (that would’ve been fine) they modified his work and failed to give source code access to their users (which is what the GPL demands).
And licenses are the easiest part. Scanning for occurrences of copyright notices deep down in the directory tree is usually more burdensome, because every singly file could contain a new copyright owner.
In theory, it could also contain a new license, but after your project has seen n license texts, it is increasingly rare to see the n+1th license text. Because there are far more people and combinations of people that license texts.
Not sure about balena, most Linux based embedded projects I worked on were based on Yocto and all the source is available either through OpenEmbedded or some vendor consortium (e.g. Linaro).
You only need to provide sources for the copyleft components you change and direct requests to the above entities for the rest.
Of course, GPL and copyleft is a kind of trick which serves the interests of the one who owns the exclusive copyrights. GPL was a real gold mine in the early days because companies didn't bother to distinguish between copyleft and permissive MIT-style licenses when using open source. It became a kind of trap to allow open source devs to monetize their copyrights by selling licenses to allow companies to keep their derived work private.
That's such an extreme position that even Stallman rejects it.
Think it over. Even Stallman, the guy who fetches web pages by mail so as to avoid running non-free JavaScript, promotes the business model of selling permission to violate the GPL to corporations.
It's okay to do it. This preserves freedom for everyone and gives you the leverage needed to negotiate a contract with a corporation. Everyone can enjoy hacking on an AGPLv3 project. The companies that can't will pay you for the privilege. They might pay you enough that you can work full time on it, maybe even hire more contributors, maybe just enjoy life.
If you're against this, then logically you are also against permissive licenses which allow all this and more. Even Stallman, the most extreme free software proponent alive today, found this to be too extreme. He didn't consider permissive licenses to be immoral, therefore he isn't against this.
I even emailed him to confirm. AGPLv3 is better because only the copyright owner gets to do it, nobody else. Permissive licenses allow everybody else to do it, no questions asked. They just give away all the leverage, completely free. One of the biggest wealth transfer in history, from well meaning developers and straight into the pockets of corporations.
[+] [-] kmeisthax|1 year ago|reply
- Centralizing copyright ownership in a single entity grants that entity the ability to lock down the project at any time and defeat the copyleft (e.g. Oracle killing off OpenSolaris). I consider this a worse outcome than a copyleft that is unenforced. It also encourages malicious enforcement (e.g. Oracle v. Google) that runs contrary to the goals of FOSS.
- Due to some very specific peculiarities of US law, regular users can sue companies that don't follow the GPL, because the source code disclosure requirement makes you a third-party beneficiary of the copyright license (which in US law is a contract).
The last one is a bit unfair to the article because the rulings in question happened after it was published. But it obviates the biggest benefit of centralized ownership - clear and unambiguous standing to sue. If things were the opposite - i.e. the courts said third-party beneficiaries can't sue and only owners can - then there would be an argument for keeping ownership of critical parts of the project in an entity with no conflict of interest against enforcement.
Even then, I don't see why ownership has to be centralized. Under US law, joint owners of a single copyrighted work both have standing to sue. Having more owners means more people with standing. In lieu of a classic CLA with a single point of failure, you could have a policy of accepting any code that is either owned by the developer itself (after their employment contracts have been vetted) or any of a number of trustworthy FOSS organizations who are committed to enforcing GPL. All parties would have standing to sue individually and could additionally sue as a class in a single action.
[+] [-] tzs|1 year ago|reply
(1) Isn't SFC vs the only case where how third-party beneficiary law applies to GPL enforcement has come up? That case has not yet gone to trial. The third-party beneficiaries have only been considered in the context of motions of summary judgement. The court ruled that this will have to be determined at trial.
(2) You can only have a third-party beneficiary to a contract when there is a contract.
The defendant should be able to defeat a third-party beneficiary claim by saying that they did not agree to the license. They saw code they wanted to use and thought it was public domain or thought their use would be covered by fair use or decided that they would go ahead and infringe its copyright because they thought the risk of the copyright owners suing was negligible.
That approach would have some risks if the copyright owners later do sue, because it would be tantamount to admitting their infringement was willful which can greatly increase statutory damages.
[+] [-] Tomte|1 year ago|reply
Isn‘t this an open question and a main point in the Vizio case where trial is still a few months off?
[+] [-] latexr|1 year ago|reply
It also grants the ability to make the project more open. I once wanted to change a project I was part of to a more permissive public domain license. Leadership was in favour but ultimately rejected it due the impracticality of dealing with getting agreement from everyone who had ever contributed (there were no CLAs). So it remained with the old license.
If an entity unilaterally changes the license, you can still fork it at the time the change was made and continue from there.
Now, I’m not defending Contributor License Agreements. I also dislike them and the hurdles they cause to contribution. Plus, the situation you described of the project becoming more locked down instead of less is likely more common, and forks can be a pain for everyone. Still, wanted to share the other side.
[+] [-] Thorrez|1 year ago|reply
I don't understand how copyright ownership of FOSS code would impact an entity locking down the project. I don't think owning the copyright gives the entity the ability to do that. Maybe owning the trademark or the Github repo would, but not the copyright.
[+] [-] rlpb|1 year ago|reply
By this logic, as well as refusing to sign CLAs you should also refuse to adopt any MIT licensed or similar software, since that can also be "locked down".
Do you?
[+] [-] kevin_thibedeau|1 year ago|reply
[+] [-] eikenberry|1 year ago|reply
[+] [-] palata|1 year ago|reply
But then following this philosophy, shouldn't you favour copyleft licenses, too? Because if it's permissive, they can suddenly go proprietary without caring "much" about copyrights, right?
I have come to these rules:
- Never sign a CLA.
- In my projects, the "most permissive" licence I use is MPLv2 (which is weak copyleft). When I release OSS software, there is absolutely no point in using a permissive license: MPLv2 should be fine for everybody. Of course sometimes I like the GPL family, and recently I've come to like the EUPL.
[+] [-] matheusmoreira|1 year ago|reply
I actually emailed Stallman to ask about the ethics of this. He replied that it's better for everyone when only the creator has this power. Permissive licenses give everyone else that power too. Copyleft licenses don't. Only the copyright owner can sublicense. Others must comply or pay for it.
[+] [-] rendaw|1 year ago|reply
And I'm not really sure I get the risk here. Projects (Redis, Terraform) changed license, the community responded by forking, and the result is at worst more fragmentation. If a company doesn't think a project is worth maintaining without a more monetizable license having multiple code owners isn't going to force them to keep maintaining the software.
I'm not saying multiple owners doesn't have benefits, but it's far from clear enough to present a cut and dried policy like this I think.
[+] [-] plagiarist|1 year ago|reply
[+] [-] bruce511|1 year ago|reply
The point of the article us that it may, or may not, be you.
I notice that you weren't clear on this part in your post, suggesting perhaps that it's not something that's front-of-mind like the CLA is.
On the CLA front I'm on the fence. Assign, don't assign, that's for each person to decide.
But the alternative to CLA is not necessarily "I keep the copyright". That's the point the article is asking you to consider.
Aside; unless you have a specific bit of paper assigning copyright to you, and assuming you have a day job, it's very unlikely that you hold the copyright even if you only do OSS work at home on weekends.
And lastly - have you ever enforced your copyright legally? If you have never enforced a copyright violation then your work is effectively public domain. Yes the threat that you could take action exists, but in practice your contributed-to-project can change their license and call your bluff.
[+] [-] munchler|1 year ago|reply
Is this really true? I haven't checked my employment agreement, but I'm pretty sure that my employer only controls the copyrights for a) work I do for them, and b) any other side work I happen to do in my employer's field (which never happens).
AFAIK, work I do on my own that is unrelated to my employer belongs to me, and I've never had anyone from my job try to assert otherwise. (I have plenty of publicly-visible code on GitHub that they could glom onto if they wanted, although none of it is commercially important.)
---
Edit: My employee agreement says "I understand that the provisions this Agreement requiring assignment of Company Work Product do not apply to any Non-Company Work Product that qualifies fully under the provisions of Section 2870 of the California Labor Code, or any similar state invention law."
That labor code says "Any provision in an employment agreement which provides that an employee shall assign, or offer to assign, any of his or her rights in an invention to his or her employer shall not apply to an invention that the employee developed entirely on his or her own time without using the employer’s equipment, supplies, facilities, or trade secret information except for those inventions that either:
(1) Relate at the time of conception or reduction to practice of the invention to the employer’s business, or actual or demonstrably anticipated research or development of the employer; or
(2) Result from any work performed by the employee for the employer."
[+] [-] Joel_Mckay|1 year ago|reply
In most of the US, all work done outside of your employers business is implicitly your own... unless explicitly stated in your employment contract that they have rights to such works.
In general, most commercial businesses won't care unless their IP or resources were misappropriated for a personal project. Best of luck =3
[+] [-] bluehatbrit|1 year ago|reply
I've never had a job actually assert anything around this personally, but I do make sure to have anything notable signed off by my employer as "mine". That's assuming it's unrelated to my employers field of course.
[+] [-] j-bos|1 year ago|reply
[+] [-] einpoklum|1 year ago|reply
From my personal experience, this really depends. Some employment agreements are stated very widely, so the employer even gets retroactive ownership of things you do in the past; some include copyrights for work you'll do in the future, after employment, in the same domain which can be said to be based on work you've done for the employer; some include all side-work regardless of domain, while you work there; some don't.
[+] [-] kps|1 year ago|reply
[+] [-] aulin|1 year ago|reply
[+] [-] bunsenhoneydew|1 year ago|reply
[+] [-] vegetablepotpie|1 year ago|reply
> The central thread here is collective action by principled people who will use copyleft primarily as a tool for rights of users and for the improvement of copylefted projects.
Joint stock companies are about hierarchy and control. Free software is very much not about that. Free software is a syndicalist movement by software developers. Software developers have taken control over computing infrastructure, we develop it on our own terms. We have settled on a decentralized model, which shares openly, without constraint.
People with the hierarchical mindset hate another party taking ownership because that’s something they don’t have control over. They would be happy to have you hunched over a keyboard desperately typing while they bark orders at you, regardless of whether or not that produces anything of value. Linux and GCC are both inspired products that grew in the cradle of copyleft, they are excellent because of their open development. Meanwhile, large corporations are happy silo themselves into unproductive morasses and play ritualistic political games [1].
Copyleft benefits users because it produces better software. Enforcement is the only card to play to make sure that continues. Unfortunately our reaction to licensing has been immature. When asked about licensing, we’re happy to throw up our hands and say “I don’t care about that” (see WTFPL) and carry on with development as if some helpful person from legal will do the legwork for us in exchange for our wonderful output. The fact is, legal is still in the 19th-century as far as intellectual property is concerned, and are happy to respond in a formal and threatening way to anything that challenges their hegemony. We have to work with our colleagues in the legal community, educate, and give them a place in our decentralized world. Otherwise, we’ll just be workers fighting for our slice of the pie in a rat race, commanded by people who are happy with consistent mediocrity. Users will suffer.
[1] http://minimsft.blogspot.com/2005/06/bob-herbold-fiefdom-syn...
[+] [-] benatkin|1 year ago|reply
OTOH there are projects like Forgejo which are copyleft but are still vendor neutral. Even though it's vendor neutral, I wouldn't be too thrilled if it were AGPL, but it's just GPL. So I am still a happy Codeberg user. (Element is AGPL)
Zulip is my favorite open source chat now. It's used by some stuff that's relevant to me right now including Bytecode Alliance and Julia.
[+] [-] palata|1 year ago|reply
Not sure I follow why AGPL is a problem, though.
[+] [-] einpoklum|1 year ago|reply
[+] [-] pabs3|1 year ago|reply
https://sfconservancy.org/copyleft-compliance/
[+] [-] nathanmills|1 year ago|reply
The article vastly overstates the importance of enforcement. In practice, the collaborative nature of modern software development makes strict copyleft enforcement unnecessary and potentially harmful to innovation. Most companies comply voluntarily because it makes business sense.
I've worked at several major tech companies and have never once encountered the kind of enforcement issues described here. This seems like a solution in search of a problem.
[+] [-] palata|1 year ago|reply
For what I see in robotics, I can say that most products I see being shipped violate hundreds (thousands?) of licenses. Both permissive (which generally require attribution) and all kinds of copyleft.
Many IoT products use stuff like https://www.balena.io/os and essentially ship products that contain docker containers of all sorts. If you ship an Ubuntu container, you ship a ton of packages with it that have license requirements, right?
Nobody cares, nobody knows, nobody wanna know. That's the situation.
[+] [-] Joel_Mckay|1 year ago|reply
The right to transfer copyrighted works may also open people to legal action from employers in some countries outside the US. i.e. the identical contract text can have two different meanings depending where it is signed.
I prefer to license most works as Apache 2.0, and this ensures people can do whatever they need to get the use-case solved in whatever legal obligation they are encumbered within.
Note, implicit personal copyright is always in effect... The original author(s) must explicitly state the work is public-domain/CC0, or you could be in violation.
From what I've seen over the years, there are a few groups of trouble makers:
1. Companies from countries that have zero software copyright/patent laws. So will cycle GPL works into the closed-source production pipeline in commercial settings. i.e. the culture views the US concept of owning ideas as absurd.
2. Folks that think linking against a LGPL shared object for compatibility reasons obligates developers divulge source-code. Note, there is source code released under several different licenses for legal compatibility reasons. i.e. the work may be fine with static linking under one version, and at the same time violate LGPL with the identical binary.
3. submarine attacks... malicious/foolish folks that distribute works they have zero legal right to re-license, re-publish, or possess. For Unity developers on US soil, the store is peppered with works still owned by Studios that can get you sued out of existence.
CC0 and Apache 2.0 are the safest options in my opinion, but one still must trust the authors aren't poisoning the chain of trust with copyright violations.
This is another reason why out-of-band package managers are dangerous to commercial entities. Microsoft will be in business for a long time yet... =3
[+] [-] Uehreka|1 year ago|reply
Like, in Welte v. Sitecom, Sitecom didn’t just ship Welte’s work with their product (that would’ve been fine) they modified his work and failed to give source code access to their users (which is what the GPL demands).
[+] [-] Tomte|1 year ago|reply
In theory, it could also contain a new license, but after your project has seen n license texts, it is increasingly rare to see the n+1th license text. Because there are far more people and combinations of people that license texts.
[+] [-] aulin|1 year ago|reply
You only need to provide sources for the copyleft components you change and direct requests to the above entities for the rest.
[+] [-] jongjong|1 year ago|reply
[+] [-] matheusmoreira|1 year ago|reply
Think it over. Even Stallman, the guy who fetches web pages by mail so as to avoid running non-free JavaScript, promotes the business model of selling permission to violate the GPL to corporations.
https://www.gnu.org/philosophy/selling-exceptions.html
It's okay to do it. This preserves freedom for everyone and gives you the leverage needed to negotiate a contract with a corporation. Everyone can enjoy hacking on an AGPLv3 project. The companies that can't will pay you for the privilege. They might pay you enough that you can work full time on it, maybe even hire more contributors, maybe just enjoy life.
If you're against this, then logically you are also against permissive licenses which allow all this and more. Even Stallman, the most extreme free software proponent alive today, found this to be too extreme. He didn't consider permissive licenses to be immoral, therefore he isn't against this.
I even emailed him to confirm. AGPLv3 is better because only the copyright owner gets to do it, nobody else. Permissive licenses allow everybody else to do it, no questions asked. They just give away all the leverage, completely free. One of the biggest wealth transfer in history, from well meaning developers and straight into the pockets of corporations.
[+] [-] globalnode|1 year ago|reply
[+] [-] bruce511|1 year ago|reply
Open Source is not designed to be "anti company". It's designed to be pro-user.
(I'm not sure why you're being down-voted, your comment is a common belief, if somewhat missing the point of OSS).
[+] [-] immibis|1 year ago|reply