Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tgppl, a new type of open-source license

electriccoin.co

Post reply on HN
Print view View original

41–50 of 74 posts

Re: Tgppl, a new type of open-source license

#41

Post by geofft »

giancarlostoro wrote: post #35
tptacek wrote: post #31

Earlier quoted context omitted.

You don't really need a new kind of license for that; you can just AGPL now, and release MIT later (assuming you're assigned the copyright for all the code).

At that rate I'd prefer close sourced now, MIT later.

The advantage of AGPL now is that you can get your code into distributions / services that require your code to be under an OSD-compatible license (like Debian, Fedora, Travis CI, etc.) or a source-available one (GitHub, etc.), but it dissuades the AWSes of the world from setting up a competitor, and it may also dissuade certain corporate users from using your OSS release instead of your enterprise one.

Re: Tgppl, a new type of open-source license

#42

Post by geofft »

ocdtrekkie wrote: post #34
nsajko wrote: post #9

This (under the same name and version 1.0) has already been presented to FSF and OSI in the 2000s and 2010 on their mailing lists and other places, so I guess it didn't get approval. Since it thus isn't an open-source license, why present it as such in article title - starting out dishonest is probably not a good idea. If I'm wrong and it is approved by OSI, that info should probably be more prominent in the blog pos…

I don't feel like we're going to make any progress in this space while a single entity is considered the sole authorizer of something being open source or not.

It's not - there are two entities (FSF and OSI), they happen to have similar definitions, and a number of important organizations (Linux distros, vendors with special plans for open-source users, employers with open-source contribution policies, etc.) all happen to have specified their definition in terms of one or both of those because they're pretty good definitions. For instance, Ubuntu's licensing policy has text that pretty closely matches the OSD's, but does not defer to the OSI for the definition. (And Debian's, of course, is the text on which the OSD was based - any changes to the OSI-maintained OSD would not necessarily flow back to the DFSG. Debian also considers some of the FSF's own licenses non-free, for good reason IMO.)

Concretely, if the OSI were to change the OSD in either a way that included things like the SSPL or that included things like the Hippocratic License, I think there's a good chance that my employer's internal OSS policies would change to say "the version of the OSD before 2020," because it's not clearly in their interest to contribute company-owned code to projects under those licenses. On similar grounds, I'd expect companies that provide free services (hosting, CI, etc.) to F/OSS projects to say "these licenses don't count," Linux distros to not universally agree on including them, etc.

So you're already in a place where there's no sole authority: you need to start by convincing everyone other than the OSI that a new sort of license is actually a good idea and the change you want to make to the OSD is actually something that they, too, should consider "open source." And once you get to the point where enough people agree with you, the OSI isn't going to be in your way in any practical sense.

Re: Tgppl, a new type of open-source license

#43

Post by cycloptic »

ocdtrekkie wrote: post #34
nsajko wrote: post #9

This (under the same name and version 1.0) has already been presented to FSF and OSI in the 2000s and 2010 on their mailing lists and other places, so I guess it didn't get approval. Since it thus isn't an open-source license, why present it as such in article title - starting out dishonest is probably not a good idea. If I'm wrong and it is approved by OSI, that info should probably be more prominent in the blog pos…

I don't feel like we're going to make any progress in this space while a single entity is considered the sole authorizer of something being open source or not.

I don't feel like we're going to make any progress either if we consider it open source to toss random code up on github under random licenses with no legal review from any outside parties whatsoever. Sorry I don't mean to be snarky but someone has to fund the lawyers and organize the committees to look over this stuff and it seems those orgs are the only ones willing to foot the bills so far. The groups pushing for newer licenses that skirt the existing definitions almost never seem to be interested in doing this, they only really care about getting someone to bend the rules for their license.

Re: Tgppl, a new type of open-source license

#45

Post by rurban »

iameli wrote: post #23

Haven't gone line-by-line on this one, but I like the new trend of "time limit" licenses. If I'm trying to start a business, something AGPL-ish might make sense in the short term to avoid bigger competitors copying everything we're doing. But that doesn't mean I want my great-grandchildren to be able to sue for violations 90 years from now. "AGPL for now, MIT later" seems like a good compromise.

You know that the Copyright started with a similar reasonable time limit. Here it's a year. But then lawyers and politicians extended the period and fine prints decade by decade, so that the original sense of the protection was overturned. Now it's a sham. Holding back fixes for one year is Apple/Microsoft like. Google also started holding back critical services for their Linux variant. No good compromise at all.

Re: Tgppl, a new type of open-source license

#46

Post by jpetso »

iameli wrote: post #23

Haven't gone line-by-line on this one, but I like the new trend of "time limit" licenses. If I'm trying to start a business, something AGPL-ish might make sense in the short term to avoid bigger competitors copying everything we're doing. But that doesn't mean I want my great-grandchildren to be able to sue for violations 90 years from now. "AGPL for now, MIT later" seems like a good compromise.

The issue with "time limit" licenses is that it effectively centralizes contributions.

As an independent developer, I won't want to write patches for a project that will have already advanced internally. Sure I can make a change, but instead of collaborative development at trunk, I have to fork the year-old codebase to make my change available to users. Or hope that the company behind the project picks it up and it becomes open source after the long waiting period.

As the company behind a "time limit" licensed codebase, this means I won't get much from the community in terms of code contributions. Patches that do get contributed are going to result in merge conflicts. Sure you can privately collaborate with selected other entities, and in that case you've reinvented the Android development model wherein the owner company (Google) privately shares code with phone vendors and releases it to the rest of the world at a later point.

In short, this model may work for companies that want the branding aspect of open source while saying no to code contributions or even community governance models. The recent KDE Free Qt brouhaha also shows that this can easily imply delayed security fixes for the open version as well as increased risks of hostile forks. I don't see this as a particularly popular model going forward, although I imagine it covers some use cases well.

Re: Tgppl, a new type of open-source license

#47

Post by notRobot »

geofft wrote: post #42
ocdtrekkie wrote: post #34

Earlier quoted context omitted.

I don't feel like we're going to make any progress in this space while a single entity is considered the sole authorizer of something being open source or not.

It's not - there are two entities (FSF and OSI), they happen to have similar definitions, and a number of important organizations (Linux distros, vendors with special plans for open-source users, employers with open-source contribution policies, etc.) all happen to have specified their definition in terms of one or both of those because they're pretty good definitions . For instance, Ubuntu's licensing policy has tex…

> Debian also considers some of the FSF's own licenses non-free, for good reason IMO.

I'm curious about this, do you know which ones?

Re: Tgppl, a new type of open-source license

#48

Post by duskwuff »

notRobot wrote: post #47
geofft wrote: post #42

Earlier quoted context omitted.

It's not - there are two entities (FSF and OSI), they happen to have similar definitions, and a number of important organizations (Linux distros, vendors with special plans for open-source users, employers with open-source contribution policies, etc.) all happen to have specified their definition in terms of one or both of those because they're pretty good definitions . For instance, Ubuntu's licensing policy has tex…

> Debian also considers some of the FSF's own licenses non-free, for good reason IMO. I'm curious about this, do you know which ones?

The GNU Free Documentation License (GFDL). It's generally well-intentioned, but it places some weird restrictions on modification and reuse. In particular, it allows the author of a text to define "invariant" sections of a text which cannot be removed or altered in copies of the work, and automatically applies this restriction to sections of a document with certain names (like "Dedication").

The GFDL also theoretically forbids users from storing GFDL-licensed documents on encrypted storage, as the license states that "You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute". I don't think that reading was intended, but the license doesn't clarify further. :)

Further analysis: https://people.debian.org/~srivasta/Position_Statement.xhtml

Re: Tgppl, a new type of open-source license

#49

Post by janoc »

ksec wrote: post #10

>Radically... I vaguely remember reading a similar Open Source License, but couldn't google it. And it reads very AGPL like. Which may be a big no no for many Cooperation and Enterprise. And what if the Author Set a Grace Period of 50 years or longer? It feels to me a solution looking for problem.

It is a solution for people who want to keep their software proprietary because they think they can't make money out of it if it is open source. All the while they get to claim credit for it being "open source".

The problem is that this license completely obliterates the major points of OSS licenses - which are open collaboration and security. Nobody is going to contribute and fix bugs in old versions of the software which may not even work anymore (e.g. because some underlying protocol or infrastructure have changed already).

Re: Tgppl, a new type of open-source license

#50

Post by amadeuspagel »

nsajko wrote: post #9

This (under the same name and version 1.0) has already been presented to FSF and OSI in the 2000s and 2010 on their mailing lists and other places, so I guess it didn't get approval. Since it thus isn't an open-source license, why present it as such in article title - starting out dishonest is probably not a good idea. If I'm wrong and it is approved by OSI, that info should probably be more prominent in the blog pos…

There's nothing dishonest about having a different definition of open source then the FSF or OSI.
Post reply on HN