Live data from Hacker News

No right to relicense this project

github.com

221–230 of 388 posts

Re: No right to relicense this project

#221
post #126

Licenses are cancer and the enemy of opensource.

There would be no open source without the gpl

MIT and BSD are doing just fine.

The 25519 crypto package that's built into practically everything these days (SSH, TLS, most e2e messaging) was released as both a spec and a C reference implementation _in the public domain_.

Re: No right to relicense this project

#222

Earlier quoted context omitted.

> This is not true. I will just give the example of the nighttime illumination of the Eiffel Tower: That example is not analogous to the topic at hand. But furthermore, it also is specific to French/European copyright law. In the US, the US Copyright Act would not permit restrictions on photographs of architectural works that are visible from public spaces.

actually, the US Copyright Act does in fact allow restrictions on photographs of architectural works that are visible from public spaces: https://en.wikipedia.org/wiki/Portlandia_(statue) the Portlandia statue is one such architectural work - and its creator is fairly litigious.

I don't know the details of that specific case so I can't speak to it, but the text of the AWCPA is very clear:

> The copyright in an architectural work that has been constructed does not include the right to prevent the making, distributing, or public display of pictures, paintings, photographs, or other pictorial representations of the work, if the building in which the work is embodied is located in or ordinarily visible from a public place.

This codifies an already-established principle in US law. French law does not have that same principle.

Re: No right to relicense this project

#223
post #166

Earlier quoted context omitted.

There's a subtext in your point that I want to expand on. Tech people, particularly engineers, tend to make a fundamental error when dealing with the law that almost always causes them to make wrong conclusions. And that error is that they look for technical compliance when so much of the law is subjective and holistic . An example I like to use is people who do something illegal on the Internet and then use the argu…

> So, when this gets to a court (which it will, it's not a question of "if"), the court will consider how necessary the source work was to what you did. If you used it for a direct translation (eg from C++ to Go) then you're going to lose. My prediction is that even using it in training data will be cause for a copyright claim. This has a lot of similarity to when colorization of film started popping up. Did colorizi…

A work could even have two copyrights! Copying a colorized film could require the permission of both the studio that made the film, and the studio that colorized it.

Re: No right to relicense this project

#224
post #38

Earlier quoted context omitted.

I think it's just the GPL family of licenses that tend tend to cause most problems. I appreciate their intent, but the outcome often leaves a lot to be desired.

The GPL exists for the benefit of end users, not developers. It being a chore for developers who want to deny their users the software freedoms is a feature, not a bug.

How does the GPL help a user who doesn't write code themselves?

Re: No right to relicense this project

#225

Does anyone understand the intent behind the changed license on the package, why are the current maintainers trying to do it in the first place? What's actually going on?

Unicode detection is the kind of utility the language maintainers want in their package collection if not in the standard library, and programmers who have to do anything with "plain text" files might want to rely on. Releasing a core library like this under a genuinely free licence (MIT) is a service to anyone working in the ecosystem.

Maybe. Enabling more GPL software to become proprietary isn't exactly a service.

Re: No right to relicense this project

#226

Does anyone understand the intent behind the changed license on the package, why are the current maintainers trying to do it in the first place? What's actually going on?

Nobody that is not already writing (L)GPL licensed software wants to pull LGPL licensed libraries into his software. I'm not a lawyer. If you have it in separate object artefacts that you can dynamically link to, you should be fine. Everything else may be more difficult.

See what FFmpeg writes on this topic: https://ffmpeg.org/legal.html

Re: No right to relicense this project

#227
post #54

Earlier quoted context omitted.

No. Because they couldnt have done any of that refactoring without a licence to do so, and that licence forbids them from relicencing it.

Ok since this is not really answered... Hypothetically, If I'm a maintainer of this project. I decided I hate the implementation, it's naive, horrible performance, weird edge cases. I'm wiser today than 3 years ago. I rewrite it, my head full of my own, original, new ideas. The results turn out great. There's a few if and while loops that look the same, and some public interfaces stayed the same. But all the guts are…

You have rights, but if it's a derivative, the original author might have rights too. If you made a substantial creative input, the original author can't copy your project without your permission, but neither can you copy theirs.

Re: No right to relicense this project

#228

Earlier quoted context omitted.

Afaik you can do whatever you like to GPL licensed code, you do not need a license to refactor it. I understand you need to publish the source code of your modifications, if you distribute them outside of your company.

You also can't relicense it to be less restrictive

Or more restrictive! There are certain exceptions permitting combinations of open-source code however.

Re: No right to relicense this project

#229

Does using the old version’s tests to create a new version make it a derivative work? That’s certainly some pretty tight coupling.

My gut feeling is no, a work is not a derivative of a compliance test suite that it passes and was used to guide it. But I'm not a lawyer.

Re: No right to relicense this project

#230

The copyright argument is a sidetrack both in the PR comment thread and here. The issue opened claims the new code is based on the old code, and therefore derivative, and therefore must be offered in a modified version of the source code under the previous license, LGPL. The complaint is the maintainers violated the terms of LGPL, that they must prove no derivation from the original code to legally claim this is a le…

The copyright argument is the only relevant argument. If the new work is a derived work of the original, then it follows by definition that the new work is under the copryight of the original's author(s). Since the original chardet was distributed by its author(s) only under the LGPL, any copy/derivative of it that anyone else creates must be distributed only under the LGPL, per the terms of the LGPL.

Now, whether chardet 7.0.0 is a derivative of chardet or not is a matter of copyright law that the LGPL has no say on, and a rather murky ground with not that much case law to rely on behind it. If it's not, the new author is free to distribute chardet 7.0.0 under any license they want, since it is a new work under his copyright.

Post reply on HN